Change:
The service fails to start, giving the following error messages in : Install a fresh copy of NixOS 18.03 in a VM under VMware Fusion 10.1.3 on macOS 10.12.x. Configure relevant parts in , e.g.: Based on the code in it seems that the contents of the file , which is scanned by , is simply too large: I tested that by creating a file (which is also scanned by ), with only part of the contents: After a few seconds, when the service tries to start again, there's only one of the previously three error messages in: The service started, the above error message is for the still remaining and too large file (to verify, let the contents of be identical to that of and notice that the other error messages comes back in the log file).
Ping, looks like you're the maintainer :) I have a test VM set up for this so I can help debug it.
FWIW, I also verified that it doesn't make a difference if the file is a regular file or a symlink, same symptoms apply. I also verified that removing the last three lines from to make it smaller works, just the same way it works with the substitute file .
My /var/log/vmware- file is littered with the same errors as yours, but the vmware service is still running. I'll note I don't have any shared folders.
Can you also report this upstream? The file does not look that big too me:
I guess I can do that, raising the question "shouldn't it be allowed to be bigger?". Regardless of what it looks like, it is evidently too big for the vmware-vmsvc code to handle as it is now :/ I'm thinking of patching the vmware service in the Nix derivation, but it would of course be better to have it done upstream or that Nix generated a smaller file.
I also ran the lsb release tool on NixOS in the VM and didn't get any output. Is that the expected result? I'm guessing not... If the lsb release tool worked on NixOS that might also solve the problem. Can you let me know if running lsb_release has any output for you?
lsb-release just ignore this file:
Can you elaborate on how the tool could solve the problem? AFAICT it just produces output. I assume you mean that if we take this output and put it in an file, the problem is solved? But the file in question would still be restricted to the same size limitations as the other files that are scanned, or is there a difference in limitation between this one and other files? FWIW, same here, not much info from :
I didn't review the openvm-tools closely enough to say but after a quick glance it appears that the source file you linked can use the output of lsbrelease to identify the distro. I wondered if adding a quick substitution in the source code to ${}/bin/lsbrelease for /usr/bin/lsb_release might be enough to identify the distro.
Reported upstream, let's hope they increase the buffer, so we don't have to require additional binaries just to make this service work.
Started working on a PR for this in .

Discussion:
stdenv.mkDerivation rec { name = "open-vm-tools-${version}"; <del> version = "10.1.10"; </del> <ins> version = "10.3.0"; </ins> src = fetchFromGitHub { owner  = "vmware"; repo   = "open-vm-tools"; rev    = "stable-${version}"; <del> sha256 = "13ifpi53rc2463ka8xw9zx407d1fz119x8sb9k48g5mwxm6c85fm"; </del> <ins> sha256 = "0arx4yd8c5qszfgw8rqyi65j37r46dxibmzqqxb096isxhxjymw6"; </ins> }; sourceRoot = "${src.name}/open-vm-tools";

nvme-cli = callPackage ../os-specific/linux/nvme-cli { }; open-vm-tools = callPackage ../applications/virtualization/open-vm-tools { <del> inherit (gnome2) gtk gtkmm; </del> <ins> inherit (gnome3) gtk gtkmm; </ins> }; open-vm-tools-headless = open-vm-tools.override { withX = false; };