20

syspolicyd is producing about 2-3TB of read on my SSD every 24 hours (since I leave my device on 24*7). This behavior began after the macOS 10.15.4 update, and has produced about 150TB read. Killing the process, restarting the computer does not help with the case. I am wondering what is this process doing to read data repeatedly, if anyone else has the same problem, and what is a potential solution. Thanks.

Device: Macbook Pro 16 (2019), macOS 10.15.4
Update: problem persists with 10.15.5; problem persists after disabling SIP

  • 1
    Did you ever figure this one out? I have the same problem on Big Sur ... – Dima Feb 03 '21 at 23:33
  • I’ve been having the same issue, Catalina, 2019 MacBook Pro, Intel processor, one thing I did notice is if I disable the Wi-Fi that stops the massive disk reading, and CPU usage, at least temporarily but when I reenable Wi-Fi sometimes it stays normal sometimes it resumes its hyper activity CPU usage and massive disk reads. – MacMind Jun 30 '23 at 17:40

3 Answers3

2

Same Macbook Pro 16 macOS 10.15.4 here.

That process verifies 3rd party software. When you open certain apps that process reads (and a lot, if the app is big). It happens to me for example when I open Photoshop 2020, it reads about 1GB.

You say you never turn it off? How much have your laptop been running? If you never power off your computer that read usage stats are not going to be wiped, so they will just keep growing, hence the huge number. If you poweroff so it starts from zero, how much syspolicyd reads in a 24h timespan?

nathedirya
  • 21
  • 3
  • 3
    That's an idea that could work, if you launch Activity Monitor as root, sudo /System/Applications/Utilities/Activity\ Monitor.app/Contents/MacOS/Activity\ Monitor you can double click on the syspolicyd process and examine which file descriptors it currently has open. (you could also use lsof but I like GUIs :p) Maybe you'll see something that gives you a hint. – kumowoon1025 May 30 '20 at 12:25
  • As I've stated in the description, the process accumulates about 3TB read everyday, regardless of my restarts or kill of the process. This behavior has not happened before 10.15.4, since I can verify with my total SSD read/write status. –  May 31 '20 at 06:17
2

spctl is the tool to manipulate system policy and/or control syspolicyd.

Try disabling SIP, enabling the root user, and running spctl --master-disable.

It should get rid of the issue, if it doesn't, then something very weird is happening.

But this isn't a fix, it's kind of like replacing a fuse with a jumper wire. So what I think you should do is nuke the security policy database: spctl --reset-default, then reenable it after a reboot: spctl --master-enable.

All these commands need to be done as root, or with sudo

Without knowing what caused the issue in the first place though, I daresay it is likely it is likely to return. It might be some malformed rule was added to your policy db and nuking it fixes the problem, but I sort of doubt that. At least by doing this, hopefully you can diagnose the issue by keeping an eye on when the problem returns (probably after you authorize an application to run - you will need to authorize every single 3rd party non-MAS app to run after the reset)

kumowoon1025
  • 1,098
  • Thanks, I will wait a day to see if it takes effect –  May 31 '20 at 06:18
  • 2
    Unfortunately, the process produced ~100G read in an hour even after completely disabling SIP and killed the process. I think there is really "something very weird happening" –  May 31 '20 at 07:31
  • 1
    What are the risks of deleting the security policy DB? Will it be re-generated and/or will anything need to be re-configured? – TheKarateKid Mar 16 '23 at 19:30
2

Give the Terminal app the "Developer Tools" privilege, i.e. via:

System Preferences > Security & Privacy > Privacy > Developer Tools

This may solve or, in my case with Catalina, significantly reduced the sys*d diskio and cpu time.

A possible cause to the problem is the notarization, therefore, the syspoliced constantly scans binaries. The Developer Tools privilege can bypass this check.

user3439894
  • 58,676
zrfrank
  • 121
  • 1
  • 1
    I my tests, that doesn't help, unfortunately – Thomas Tempelmann Sep 06 '21 at 13:30
  • A possible cause to the problem is the notarization, therefore, the syspoliced constantly scans binaries. The Developer Tools privilege can bypass this check. This makes total sense to me. Enabling DevTools for iTerm did the trick for me. Cheers! – SaxDaddy Dec 07 '23 at 05:35