New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unload nfsd on OS X when all vagrant boxes are halted #8103

Open
deviantintegral opened this Issue Dec 9, 2016 · 6 comments

Comments

Projects
None yet
6 participants
@deviantintegral
Copy link
Contributor

deviantintegral commented Dec 9, 2016

As of OS X 10.12, the nfsd process now holds a persistent assertion preventing sleep. This is mostly a good thing, as it lets NFS work on networks where wake-on-lan packets don't work. However, this means that when plugged in, OS X will no longer automatically sleep. If you unload the daemon, sleep works fine, and I noticed that vagrant starts nfsd if required on vagrant up.

It would be nice if there was some global configuration setting to stop nfsd when all boxes are stopped, probably off by default in case other shares are being used.

@negnetsolutions

This comment has been minimized.

Copy link

negnetsolutions commented Mar 30, 2017

This is now worse with 10.12.4 as a call to nfsd stop is no longer supported when system integrity protection is turned on. Thus the only way to let the machine sleep is to prune /etc/exports and restart nfsd. It would be nice to at least add a cli command to have vagrant prune /etc/exports (so we can script in when we want nfs pruned) or even better have it automatically prune exports on suspend and halt and re-add on wake and up.

@shirazd

This comment has been minimized.

Copy link

shirazd commented Jun 17, 2017

Any resolution for this yet?

@tisba

This comment has been minimized.

Copy link

tisba commented May 28, 2018

After quite some time struggling with identifying the reason why my MacBook does not sleep, I found this issue. Thanks @deviantintegral for reporting! 👍

@daprice

This comment has been minimized.

Copy link

daprice commented Sep 19, 2018

I’d like to mention that this issue prevented me from using my laptop for a while today because it stayed awake while unattended during a power outage and drained the battery (I think it woke because of a network request unrelated to Vagrant—all my vagrant boxes were halted—and then was blocked from going back to sleep), in case that has any bearing on the priority of finding a resolution.

@tisba

This comment has been minimized.

Copy link

tisba commented Sep 24, 2018

I'm currently using wrapper scripts around vagrant up/halt in my projects. I'm trying to detect if on a halt other Vagrant VMs are still running and if that's the case, I'm basically doing a (echo -n "" | sudo tee /etc/exports) && sudo nfsd restart (see also my dotfiles).

That's not very pretty but works in my case as Vagrant is the only program working with nfsd in my case.

A better solution would be for vagrant halt to remove it's exports as Vagrant should be aware of which exports do exist.

@tisba

This comment has been minimized.

Copy link

tisba commented Nov 7, 2018

Quick update on how I mitigate the problem.

Since Vagrant 2.1 there is support for triggers. So I use triggers to clean up /etc/exports on vagrant halt:

  vm_config.trigger.after(:halt) do |trigger|
    trigger.info = "Purging NFSD exports"
    trigger.ruby do |_env, _machine|
      etc_exports = Pathname.new("/etc/exports")

      if etc_exports.exist? && etc_exports.size > 0
        system(%q{sudo cp /dev/null /etc/exports && sudo nfsd restart})
      end
    end
  end

This is sufficient for me, but it could be adjusted only to purge the exports from the machine that is being halted and if /etc/exports is empty after the cleanup, nfsd restart could be triggered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment