13

I recently updated to macOS Sierra 10.12.4 Beta (16E144f) and it might be what is causing sudo to delay up to 10 minutes as it's the most recent change I recall since this problem occurred. I have never had to wait so long for a basic program and something is clearly wrong. The command eventually succeeds, but after waiting way too long.

I've been using this question as a reference. So far, I've tried adding my hostname to the end of the 127.0.0.1 line in /etc/hosts as well as. I checked /etc/resolv.conf and I did have some extra entries from when I was on a network that needed manual DNS entries, but I removed them and there has been no difference. I used the networksetup -setdnsservers command to restore the original values. Internet still works fine but still a very slow sudo.

I tried the logger 'test' command thinking it would write to /var/log/system.log, but it looks like it totally deleted that file although it was soon made anew.

I was hoping to use the strace command to see what was happening while sudo ran but that command is not available on OS X. Has anyone ran into this problem on this operating system before?

/var/log/system.log has the following messages that may be relevant. Again the command does eventually succeed as normal:

Feb  1 00:07:39 mycomputer com.apple.xpc.launchd[1] (com.apple.imfoundation.IMRemoteURLConnectionAgent): Unknown key for integer: _DirtyJetsamMemoryLimit
Feb  1 00:07:56 mycomputer com.apple.xpc.launchd[1] (com.apple.quicklook[2355]): Endpoint has been activated through legacy launch(3) APIs. Please switch to XPC or bootstrap_check_in(): com.apple.quicklook
Feb  1 00:08:16 mycomputer System Preferences[1886]: I can not do what i want
Feb  1 00:11:23 mycomputer com.apple.xpc.launchd[1] (com.apple.opendirectoryd[2335]): Service exited with abnormal code: 70
Feb  1 00:12:07 mycomputer syslogd[54]: ASL Sender Statistics
Feb  1 00:16:35 mycomputer com.apple.xpc.launchd[1] (com.apple.opendirectoryd[2395]): Service exited with abnormal code: 70

Any help would be appreciated.

  • Does it matter which command you run through sudo? How do the time stamps in the log relate to your action of executing sudo and on sudo running through? I see opendirectoryd in there, do you work with a local account or a network account? What happens if you switch users (or set up a new one locally), is sudo slow there as well? – nohillside Feb 1 '17 at 8:51
  • I'm running the same beta and sudo is fast as always actually. – nohillside Feb 1 '17 at 8:51
  • 1
    @patrix Ah okay. Yes it very well could be something else. Yes it happens no matter what command I use with sudo, the delay is consistent. Basically, the command starts around that log line about com.apple.quicklook and finally finsihes at the end, so in that example it was about 8 minutes with all those messages in between. The opendirectoryd message seems to occur whenever it finally runs sudo ls in my local home directory. Right now I'm only working with local folders. I only have one user on this computer although I can see what happens with a new account... – Spencer Williams Feb 1 '17 at 15:24
  • @patrix I have just made another user with admin privileges. Sadly, that account is having the very same problem. – Spencer Williams Feb 1 '17 at 16:41
11

ErikMH's answer gave me the idea to first just try to revert the sudoers file, without reverting/upgrading my whole system again. So in short:

  1. Run this to get a root shell: sudo -s
  2. Make a copy of /private/etc/sudoers
  3. Run: cp /private/etc/sudoers\~orig /private/etc/sudoers
  4. Fix permissions by running: chmod 440 /private/etc/sudoers ; chown root:wheel /private/etc/sudoers
  5. Move any files in /private/etc/sudoers.d/ away from there
  6. Test out sudo in another terminal
  7. Don't forget to exit this shell to prevent inadvertently running commands as root when you don't mean to

Now running sudo should work again.

Next step is to check the differences between the old sudoers file (you copied away in step 2) and the current one and add those changes step by step back to /private/etc/sudoers or /private/etc/sudoers.d/, each time running a command using sudo to check if the change breaks it.

In my case, I had specified a nonexistent group in the sudoers file. Correcting that fixed my issue.

  • worked on macOS 10.13! – Nisba Oct 24 '17 at 13:02
  • Worked for me as well (OSX 10.13). Also had the same problem - nonexistent group in sudoer file. – Petr Cibulka Dec 9 '17 at 19:23
  • Hmm... I don't remember changing the sudoers file on the machine where I had this problem, but I wish I had tried what you suggest instead of restoring my system. – Spencer Williams Dec 31 '17 at 16:03
  • I went ahead and accepted your answer because it looks like people are confirming that it helps, and I sure wish I had tried this first, nor do I generally recommend restoring your whole system. – Spencer Williams May 21 '18 at 22:09
2

This can occur when upgrading to 10.12.4 if you’ve ever edited the /private/etc/sudoers file.

Easiest solution is:

  1. Drop back to a previous version of the system (you always clone your system before updating, right?)
  2. Delete /private/etc/sudoers
  3. Copy /private/etc/sudoers~orig to sudoers
  4. Reset the ownership of sudoers to system/root — read-only
  5. Upgrade the system to 10.12.4
  • "This can occur when upgrading to 10.12.4 if you’ve ever edited the /private/etc/sudoers file." Do we know what is actually causing it? – Wowfunhappy Apr 3 '17 at 15:02
1

I wish I could have found the actual cause of this, but I could only resolve the problem after restoring the system software. I was previously on the Public Beta of macOS Sierra but now I'm on the main one.

I am slowly loading back all my programs and I will note if I experience a delayed sudo again.

0

I had a file in /etc/sudoers.d/ that I removed. Voila - sudo is fast again.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .