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?

Improve this question
13
  • Do the suggestions in apple.stackexchange.com/questions/25474 affect the log in time?
    – Graham Miln
    Oct 25, 2020 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, 2020 at 0: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, 2020 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, 2020 at 5: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, 2020 at 19:36

1 Answer 1

Reset to default
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.

Improve this answer
1
  • 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, 2021 at 12:00

You must log in to answer this question.

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