Disabling photoanalysisd

disabling-photoanalysisd.md

For what it's worth (and with all the usual disclaimers about potentially making your mac unstable by disabling system services), here's some commands that will manipulate this service and services like it. Note the $UID in the command, that's just a bash shell variable that will resolve to some number. That's your numeric UID. You just run these commands from a Terminal command line. No special privileges needed.

If you want to disable it entirely, the first command stops it from respawning, and the second kills the one that is currently running:

launchctl disable gui/$UID/com.apple.photoanalysisd
launchctl kill -TERM gui/$UID/com.apple.photoanalysisd

(If you kill it without disabling it will die, but a new one will respawn and pick up where the old one left off)

I don't have this problem myself, so I can't try these next two commands. They're relying on good ole UNIX signals. You could theoretically suspend and resume the process like this ("STOP" and "CONT" are stop and continue):

launchctl kill -STOP gui/$UID/com.apple.photoanalysisd
launchctl kill -CONT gui/$UID/com.apple.photoanalysisd

I don't know what launchd does when running processes are suspended for a long time. Will it detect them as dead and kill and restart them? I dunno. But I do know they won't get any CPU time.

Installing OpenCore on a real Mac is pretty straightforward. Just set-up the kext, lets see if it works.

Though it appears to only be for Intel Machines. The ARM ones all have Metal 2, so the kext might not work for those

Safe solution for Ventura and up

Apple really locked this up by now, so none of the ideal previous approaches here work anymore.

Deleting/moving the binaries/.plist files? Good luck with that, not happening (See the possible "permanent fix" solution for details on why) launchctl disable? Sure it pretends to work and adds the "disabled" entry, but it doesn't remove the enabled entry so its effectively useless, amazing. launchctl kill? Error, "Not privileged to signal service.", even with sudo or regardless of the signal or syntax you try, it won't let you.

The only option left now is to just repeatedly kill the process itself, which we can do with a cron job:

#!/bin/bash
killall -SIGINT mediaanalysisd
killall -SIGINT mediaanalysisd-access

@jhmaster2000
Thanks for the detailed write-up. I came to the same conclusion: not to go with the route of modifying the root partition by disabling SIP, as it seems too risky. I resorted to your cronjob method; however, I found that mediaanalysisd is being restarted within 10 seconds. Given this, I'm wondering if it's even worth using cron since its resolution is 1 minute. That said, I have a question for you: do you know how often mediaanalysisd is restarted on your Mac? Thank you.

@aselvan I also did not want to disable SIP and went with the cronjob workaround. As you said, it is not perfect because the daemon restarts often but my Intel based macOS device got a lot cooler in average. I hope Apple fixes the root cause.

@aselvan I also did not want to disable SIP and went with the cronjob workaround. As you said, it is not perfect because the daemon restarts often but my Intel based macOS device got a lot cooler in average. I hope Apple fixes the root cause.

@cbratschi I guess you are right; it's better than nothing. After observing the restart frequency for a while, I noticed it is highly unpredictable—sometimes restarting every 10 seconds, and sometimes no restart for a couple of minutes! I decided to run the cron job every minute, protecting the run with flock to avoid potential multiple runs with race condition.

I resorted to your cronjob method; however, I found that mediaanalysisd is being restarted within 10 seconds. Given this, I'm wondering if it's even worth using cron since its resolution is 1 minute. That said, I have a question for you: do you know how often mediaanalysisd is restarted on your Mac? Thank you.

@aselvan quoting myself:

As for the interval that is also up to you based on how aggressive your instance of photo/mediaanalysisd is being about restarting itself, some people here have mentioned it popping back up within a minute, but mine seems more tame, so I picked every 3 minutes and it seems good enough for my case.

So far, the above has remained true for me, and I haven't had any more incidents with unexpectedly hot device since, so I stopped paying attention to it, therefore I couldn't say how often it's been spawning, since I also disabled cron logging to prevent it from becoming a silent disk space devourer. But I did just stare at Activity Monitor for 3 minutes filtering for it and it didn't even appear (I've spotted it occasionally running at other times though, so it's not gone, just very tame)

If you need to run it aggressively in your case, there are solutions to run cron more frequently, see: https://stackoverflow.com/questions/30295868/how-to-setup-cron-job-to-run-every-10-seconds-in-linux (works all the same for MacOS)

Alternatively, I did also find a potential different solution, northpolesec/santa, which might be able to prevent the process entirely(?) but I have not tested it yet since as I said cron has been working fine for me so I feel it's unnecessary for me personally to bother with now, so I can't directly confirm it works, but it does seem promising so might be worthwhile checking out for you.

As for the interval that is also up to you based on how aggressive your instance of photo/mediaanalysisd is being about restarting itself, some people here have mentioned it popping back up within a minute, but mine seems more tame, so I picked every 3 minutes and it seems good enough for my case.

Thanks for your response. In my case, the restart intervals are wildly random, ranging from 10 seconds to 1, 2, 3, or even 5 minutes, all in an unpredictable pattern. I decided to run the cron job every minute so that, in the worst-case scenario, these CPU hoggers will only run for up to a minute. It is not a good idea to go lower than a minute with the methods discussed on that link. Even for 1 min, I had to protect the runs with flock to prevent them from stepping on each other due to potential race conditions like so below.
*/1 * * * * /opt/homebrew/bin/flock -no /tmp/kill_pigs.lock ${SCRIPTS_GITHUB}/macos/macos.sh -ckill

Alternatively, I did also find a potential different solution, northpolesec/santa, which might be able to prevent the process entirely(?) but I have not tested it yet ...

Thanks for the link. That sounds interesting. I will check it out; if not for this purpose, it's still a good thing to check out.

It sounds like you're taking a very practical approach to managing resource-intensive processes on your system with cron jobs and flock. Using flock to prevent race conditions is a smart move, especially given the variable timing of these processes restarting. Your strategy ensures that the system doesn't get overwhelmed by multiple instances of the same script running simultaneously. Regarding the alternative solution with northpolesec/santa, it is indeed a different type of tool. Santa is essentially a binary whitelisting and blacklisting system for macOS, which could potentially give you more control over which processes are allowed to run on your machine. If the troublesome processes can be identified by their binaries, Santa could help you prevent them from running altogether, rather than just killing them after they start. Using Santa might provide a more preemptive approach, stopping the processes from launching in the first place, which could be more efficient than killing them post-launch. However, it would require some setup and testing to ensure it targets the correct processes without affecting other necessary operations on your system. It would be worthwhile to experiment with Santa in a controlled environment to see if it meets your needs. This could ultimately provide a more stable solution to managing system resources impacted by these aggressive processes. If you decide to go that route and need any help setting it up or understanding how it works, feel free to reach out!

…

On Fri, Feb 21, 2025 at 9:11 PM Arul Selvan ***@***.***> wrote: ***@***.**** commented on this gist. ------------------------------ As for the interval that is also up to you based on how aggressive your instance of photo/mediaanalysisd is being about restarting itself, some people here have mentioned it popping back up within a minute, but mine seems more tame, so I picked every 3 minutes and it seems good enough for my case. Thanks for your response. In my case, the restart intervals are wildly random, ranging from 10 seconds to 1, 2, 3, or even 5 minutes, all in an unpredictable pattern. I decided to run the cron job every minute so that, in the worst-case scenario, these CPU hoggers will only run for up to a minute. It is not a good idea to go lower than a minute with the methods discussed on that link. Even for 1 min, I had to protect the runs with flock to prevent them from stepping on each other due to potential race conditions like so below. */1 * * * * /opt/homebrew/bin/flock -no /tmp/kill_pigs.lock ${SCRIPTS_GITHUB}/macos/macos.sh -ckill Alternatively, I did also find a potential different solution, northpolesec/santa <https://github.com/northpolesec/santa>, which *might* be able to prevent the process entirely(?) but I have not tested it yet ... Thanks for the link. That sounds interesting. I will check it out; if not for this purpose, it's still a good thing to check out. — Reply to this email directly, view it on GitHub <https://gist.github.com/huksley/564be2c903312bcee7dffe415d128f90#gistcomment-5449187> or unsubscribe <https://github.com/notifications/unsubscribe-auth/A72KQ3PEGEWJGC4DT6A7GQ32Q7TGJBFKMF2HI4TJMJ2XIZLTSKBKK5TBNR2WLJDUOJ2WLJDOMFWWLO3UNBZGKYLEL5YGC4TUNFRWS4DBNZ2F6YLDORUXM2LUPGBKK5TBNR2WLJDHNFZXJJDOMFWWLK3UNBZGKYLEL52HS4DFVRZXKYTKMVRXIX3UPFYGLK2HNFZXIQ3PNVWWK3TUUZ2G64DJMNZZDAVEOR4XAZNEM5UXG5FFOZQWY5LFVA4TSMBVHA2TAOFHORZGSZ3HMVZKMY3SMVQXIZI> . You are receiving this email because you commented on the thread. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub> .

Santa is essentially a binary whitelisting and blacklisting system for macOS, which could potentially give you more control over which processes are allowed to run on your machine. If the troublesome processes can be identified by their binaries, Santa could help you prevent them from running altogether, rather than just killing them after they start.

Sounds very interesting, and I will definitely check it out. It is a better approach than a cron job for sure. Given that Apple will likely ignore this and continue to add "features" that no one asked for with no ability to stop or disable them, a solution like this, though not ideal, is the only option we have.

As for the interval that is also up to you based on how aggressive your instance of photo/mediaanalysisd is being about restarting itself, some people here have mentioned it popping back up within a minute, but mine seems more tame, so I picked every 3 minutes and it seems good enough for my case.

One interesting thing I found is, when I disabled the Spotlight (another thing I don't need or care) completely on all volumes, I noticed the frequency of restarts slowed down to 3 tries every minute and nothing for almost 45 minutes (see the log below). So I changed my cron runs to 5 minutes which works well.

$ log stream  |grep --line-buffered 'Activity'|grep --line-buffered "mediaanalysisd: (libsystem_secinit.dylib"
2025-02-22 10:01:05.686981-0600 0x146a3    Activity    0x408c0              10415  0    mediaanalysisd: (libsystem_secinit.dylib) AppSandbox
2025-02-22 10:02:11.958896-0600 0x148ce    Activity    0x41030              10470  0    mediaanalysisd: (libsystem_secinit.dylib) AppSandbox
2025-02-22 10:03:01.555609-0600 0x14ada    Activity    0x411c0              10571  0    mediaanalysisd: (libsystem_secinit.dylib) AppSandbox
2025-02-22 10:47:30.378942-0600 0x1a216    Activity    0x47260              13266  0    mediaanalysisd: (libsystem_secinit.dylib) AppSandbox
2025-02-22 10:48:03.646497-0600 0x1a3aa    Activity    0x47a80              13329  0    mediaanalysisd: (libsystem_secinit.dylib) AppSandbox
2025-02-22 10:49:10.554892-0600 0x1a5fd    Activity    0x48320              13390  0    mediaanalysisd: (libsystem_secinit.dylib) AppSandbox
2025-02-22 11:45:45.342737-0600 0x211d1    Activity    0x4ef80              16666  0    mediaanalysisd: (libsystem_secinit.dylib) AppSandbox
2025-02-22 11:46:01.902311-0600 0x212d6    Activity    0x4f690              16722  0    mediaanalysisd: (libsystem_secinit.dylib) AppSandbox
2025-02-22 11:47:09.109400-0600 0x21501    Activity    0x4fea0              16778  0    mediaanalysisd: (libsystem_secinit.dylib) AppSandbox
2025-02-22 12:00:30.359343-0600 0x22f8d    Activity    0x52200              17571  0    mediaanalysisd: (libsystem_secinit.dylib) AppSandbox
2025-02-22 12:45:30.376616-0600 0x28489    Activity    0x57710              20149  0    mediaanalysisd: (libsystem_secinit.dylib) AppSandbox
2025-02-22 12:46:04.513946-0600 0x285fa    Activity    0x57ea0              20205  0    mediaanalysisd: (libsystem_secinit.dylib) AppSandbox
2025-02-22 12:47:10.967120-0600 0x28863    Activity    0x587c0              20270  0    mediaanalysisd: (libsystem_secinit.dylib) AppSandbox
2025-02-22 13:32:16.070683-0600 0x2defd    Activity    0x5e710              22863  0    mediaanalysisd: (libsystem_secinit.dylib) AppSandbox
2025-02-22 13:45:45.328875-0600 0x2f85d    Activity    0x60570              23608  0    mediaanalysisd: (libsystem_secinit.dylib) AppSandbox
2025-02-22 13:46:02.428745-0600 0x2f958    Activity    0x60c80              23663  0    mediaanalysisd: (libsystem_secinit.dylib) AppSandbox
2025-02-22 13:47:09.197424-0600 0x2fb90    Activity    0x61470              23722  0    mediaanalysisd: (libsystem_secinit.dylib) AppSandbox

While I was at it, I also added a few other things to my kill list that I don't use or care about, which keep spawning for no reason at all. The total list is below. note: I don't use stock widget or photos or cloud sync etc.

mediaanalysisd mediaanalysisd-access photoanalysisd photolibraryd cloudphotod Stocks StocksKitService StocksWidget StocksDetailIntents
Finally, if anyone is interested, you are welcome to use my script https://github.com/aselvan/scripts/blob/master/macos/macos.sh from my github (available with brew as well). Setup a cronjob as shown below (SCRIPTS_GITHUB is the environment variable pointing to the scripts install directory). There are many other scripts in that repo that you may find useful as well.

SCRIPTS_GITHUB="/Users/arul/src/scripts.github"
*/1 * * * * /opt/homebrew/bin/flock -no /tmp/kill_pigs.lock ${SCRIPTS_GITHUB}/macos/macos.sh -ckill -v >/tmp/kill_pigs.log 2>&1