1

For some time now, Mail.app takes three minute or more to display its window, and for that interval, is labeled "not responding." There are several things that are related somehow:

  1. During that interval, fseventsd consumes 82%±3% of CPU.
  2. If we run /usr/sbin/repairHomePermissions, Mail launches normally, but the fix only lasts a couple of days.
  3. If we rebuild mailboxes, it is not fixed; if we remove all the IMAP accounts and reinstall them, it is not fixed; but if we rebuild mailboxes after that reinstall, it is normal, but again, only for a day or two.
  4. If we remove everything from /Library/LaunchDaemons, and reboot, it works normally. Did that today, so I don't know yet how long it will last.

Here is what was in LaunchDaemons:

com.acapelagroup.iVoxHelper.plist
com.adobe.ARMDC.Communicator.plist
com.adobe.ARMDC.SMJobBlessHelper.plist
com.apple.installer.osmessagetracing.plist
com.barebones.authd.plist
com.malwarebytes.HelperTool.plist
com.malwarebytes.mbam.rtprotection.daemon.plist
com.malwarebytes.mbam.settings.daemon.plist
com.oracle.java.Helper-Tool.plist
com.paragon-software.installer.plist
com.paragon-software.ntfs.loader.plist
com.paragon-software.ntfsd.plist
com.prey.agent.plist
homebrew.mxcl.dnsmasq.plist
homebrew.mxcl.mysql.plist
homebrew.mxcl.unbound.plist
org.macports.rsyncd.plist

I believe all of that has been around for longer than the problem. I recently got a new 2019 MBP with Catalina, upgraded to Big Sur, and used Migration Assistant to bring everything in from a 2012 MBP with Catalina. This problem never occurred on the old MBP, and I think (not certain) that it did not start immediately on the new one. I'm fairly sure I used it for weeks before this started happening.

Ideas? It's going to take two days to find out whether removing some LauchDaemon is a permanent fix, and if so, weeks to figure out which one. And it would still be a mystery how it interacts with permissions and mailboxes.

fseventsd is known to suck up CPU for Time Machine, but this problem has happened with Time Machine turned off and when the TM disks aren't even plugged in. And opening Mail should be making roughly the same disk actions each time it is launched.

https://arstechnica.com/gadgets/2007/10/mac-os-x-10-5/7/

https://discussions.apple.com/thread/1502226

Another oddity (but I think it's unrelated) is that Photos.app is allegedly using a lot of energy when the Dock, ps -ef, and Activity Monitor all say Photos is not running. (Though sometimes, photoanalysisd appears in Activity monitor briefly.)

4
  • I would probably set up a new Mail account for testing with some limited and basic emails. This is starting to look like the Mail you downloaded ( which would mean a slow launch with no network) or the servers slow to respond ( fast launch with no network ). – bmike Feb 6 at 0:09
  • If it is due to the quantity of Mail, then (1) nothing would make it launch instantly for a day or two and then get slow again; (2) it wouldn't have started suddenly after working fine through all the previous months. And the none of the temporary fixes in anyway changed the network functions. – WGroleau Feb 6 at 3:04
  • It’s almost certainly your mail data. 1) your IMAP server and network will vary in speed 2) that’s the nature of things breaking - first they work, then they don’t. - I’ll make a proper answer so I can expand on things. Do you have AppleCare or a business sales contact at Apple? – bmike Feb 6 at 3:15
  • The Apple Care guy keeps finding articles for different things to try. At least he understands what he’s reading, unlike the tech support in some places. It’s a bit too much coincidence for seemingly unrelated things done on the Mac to magically speed up the IMAP server in another state. – WGroleau Feb 6 at 8:15
1

Let’s see what Mail is doing:

  1. Run the following Terminal command to enable kernel symbolication: $ sudo nvram boot-args="keepsyms=1"
  2. Reboot your machine and don’t open any apps except for Terminal.
  3. Open Mail and wait a few moments for it to reach its steady-state unresponsiveness.
  4. Run the following command in Terminal, making sure you’re only running it during the window of time that Mail is unresponsive: $ sudo spindump -reveal -noProcessingWhileSampling
  5. After waiting for 10 seconds to collect a sample and another minute or two to symbolicate and format, you’ll get a file in /tmp/spindump.txt that contains a stackshot of every process.
  6. Upload the file to PasteBin or some equivalent place and we can take a look to see what Mail’s main thread is blocked on.
2
  • This is a great technique to avoid needing Insoector to look at things. The sysdiagnose path is so heavy weight. – bmike Feb 6 at 16:16
  • This sounds like a good one. Last time I looked (with all the LaunchDaemons gone), it was only taking three or four seconds to open, but if it keeps slowing down, I can try this. The Apple guy is supposed to call back Monday, but I can throw darts as well as he can. – WGroleau Feb 6 at 16:53
0

It’s almost certainly your IMAP server and the specific data it delivered to your Mac, but let’s first isolate other easy tests as follows.

  1. Make a brand new user account on the mac.
  2. Make a brand new email account on your provider(s) of choice.

Test with the new user account and new email accounts. This will tell you if mail is broken, the system is broken or the provider is broken.

Most of the time, it’s not those things and is related to the actual mail content being downloaded and synced and speed of the IMAP provider, but those are very hard to dissect and troubleshoot so I start with the easy steps first. Keep notes, since if you need to work with your provider - they will avoid having to repeat those tests or make it quick to rule out your Mac or your mail program or the OS.

1
  • The mail has already been downloaded when the problem occurs. – WGroleau Feb 6 at 8:15

You must log in to answer this question.

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