4

Recently, I poured water onto the keyboard of my MacBook 2017 (4 thunderbolt), and I forced shutdown it. After letting it dry for two weeks, I opened it and everything seems to work. It also passes the Apple Hardware Test.

However, login (login window, switching user, authenticating for root permission, terminal login) is extremely slow, taking around 20 to 40 seconds. After restarting a couple of times, the behavior does not change. After reinstalling macOS 10.13.6, High Sierra, (keeping application and data), the behavior persists. After starting up in Safe Mode and restarting, the time shortened a little bit.

To verify that this is not a hardware problem, I copied the system partition to another MacBook Pro (same generation) and I can see the same behavior, suggesting that this is a software issue.

Update: On the other MacBook Pro, I run chflags -R noschg,nosappnd,nouchg,nouappnd / and boot up the machine in Safe Mode (and rebooted). The issue was gone, but only for Safe Mode. Starting again in normal boot recreates the problem, and further Safe Mode cannot correct it.

Things I have tried on my other MacBook Pro that does not work:

  • Reinstall macOS High Sierra
  • Removing caches and user added filesystems/extensions/launchdaemons/launchagents
  • Upgrade to Mojave (login for login window is extremely fast, but terminal login is still slow. Plus it deletes all the files I have in root account (downloads, desktop, documents, etc.)
  • Partial copy done by Carbon Copy Cloner from my mac because it disconnected after a certain while in Target Disk Mode. System work and login is fast. But for some reason I forget I erased the system and did a full copy again.
  • Repaired home permissions using diskutil resetUserPermissions / 501 then 502, 503, etc.
  • Repaired disk permissions using https://www.firewolf.science/2016/07/repairpermissions-v3-now-supports-repairing-permissions-on-macos-mojave/

The output of dtruss login root is here.

The output of sample login as instructed here: here The main cause is semaphore_wait_trap, but I don't know how to debug it.

How can I troubleshoot this problem?

Joy Jin
  • 2,733
  • Do the suggestions in https://apple.stackexchange.com/questions/25474 affect the log in time? – Graham Miln Oct 25 '20 at 14:08
  • First, the account in use is root account, which should be able to read/write anywhere even when there is incorrect permission. I will still try the command. Second, this behavior can be replicated even for a new account, so this is unlikely a permission issue. – Joy Jin Oct 26 '20 at 00:41
  • Is it feasible to try the same System partition copy in reverse, copying from the stable Mac to the suspect one? – Robbie Goodwin Oct 26 '20 at 13:39
  • @RobbieGoodwin I had a ton of files, preferences, applications, and CLI programs/libraries. It would cost way too much time to start from scratch. Also, this is not a hardware but a software problem. I don't have a stable system with all my data- I have snapshots (CCC snapshots) but these are deleted by the system reinstall (which is not supposed to happen, but it does). – Joy Jin Oct 27 '20 at 05:02
  • That's scary and it's a going sideways, too. If your files/prefs/stuff matter, they should be fully backed up. My own excuse is complacency about fixing my damaged backup but how much money and time would it take to clone everything?

    Back at the ranch yes, the point is that this looks like not a hardware but a software problem… in which case it should go away if…

    – Robbie Goodwin Oct 27 '20 at 19:36
  • When you upgraded, did you erase the drive and install the new OS? If not, then the issue will still be present by virtue of the old files/configurations/etc. are still there. Don't make this overly complex. Mojave requires 13GB of space. Get a 16GB or 32GB USB3 (for speed). This SanDisk works great. Install macOS onto this and boot. Do you still have slow login? – Allan Nov 18 '20 at 00:26
  • @Allan I don't have problems in Mojave, but I don't want to upgrade right now because file migration is too complicated. I will definitely upgrade to Mojave eventually, like how I upgraded to High Sierra from Sierra (clean install and no settings migration), after I learned about new bugs introduced in Mojave and compatibility changes. – Joy Jin Nov 18 '20 at 03:15
  • Sorry...bit confused...3rd bullet point says "upgraded to mojave." But, either way, try installing macOS (Sierra, HS, El Cap, doesn't matter) onto the USB - it's just for testing. – Allan Nov 18 '20 at 03:18
  • Only way I know is to run the installer. You don't have to do it on that particular computer, you can do it on any Mac actually - just make sure they both support the OS you want to boot. – Allan Nov 18 '20 at 04:09
  • @Allan I just did that and the new system works very well. Login is extremely fast. So I guess it's probably not a hardware problem but instead related to system configuration. – Joy Jin Nov 21 '20 at 02:48
  • And just in case it might help someone, I used autoDMG to install macOS onto a dmg and then used Carbon Copy Cloner to copy the system partition on the dmg to a partition of an external hard drive. This way you can do other things while the system is being installed. – Joy Jin Nov 21 '20 at 02:50
  • And if it's convenient for you, can you explain how to create a launchd job? https://apple.stackexchange.com/a/379428/320223 – Joy Jin Nov 21 '20 at 02:53
  • Does opening a new terminal tab go slow as well? Reinstall OS? :) – rogerdpack Feb 07 '22 at 23:29

1 Answers1

1

I had the same problem everywhere authentication is needed after upgrading to High Sierra. Sampling login process gave similar output where ODRecordAuthenticationAllowed takes longer to complete than usual. The call graph shows that the authentication request dispatched from transaction_simple probably encountered some multithreading issue as caught by semaphore_wait_trap that consumed most of the runtime. So, something else must have been busy with authentication ALL the time. In my case the culprit turns out to be the printer. After updating the printer's driver and changing to use AirPrint from CUPS, login, terminal, browsing etc. are now all working to normal, and sampling login process again produces nothing as now the authentication request is too fast to catch.

  • I tried deleting all the printers, but it does not solve the problem. What does solve the problem is to replace the opendirectory information from an earlier backup. – Joy Jin Mar 21 '21 at 12:00