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.

Greetings from the year of 2025, and 6+ years later MacOS Sequoia is still plagued by these evil bloatware, and Apple made them harder than ever to deal with!

If you are on Big Sur (11) or newer, forget about all* the above solutions, none will work!

*(Except for @mailinglists35 solution above which presumably works for Big Sur and Monterey, but will not work for Ventura and up)

Firstly, if you are looking for a way to truly exterminate all traces of photo/mediaanalysisd from your system without a doubt (like @ElectronHerder's method), I regret to tell you it is likely impossible now and highly intrusive to attempt, but I'll leave some notes and references on the state of the "permanent fix" methods now from what I've found researching, at the bottom of this post for those truly interested and daring enough to risk it (I ultimately decided I did not want to risk my own device after researching them, so I cannot say for certainty they even work).

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

Note: I did not include photoanalysisd because I personally haven't seen any activity from that process on my device yet, only mediaanalysisd has given me trouble, but you can easily just add photoanalysisd in there if you need it too.

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.

Notice the -SIGINT signals, those are important, since they seem to be more effective and keep the process down longer than a regular default SIGTERM does.

For anyone reading this unfamiliar with cron on Mac here's a short rundown on how to use this:

1. Save the above codeblock in a .sh file somewhere permanent (e.g: /Users/[your_username]/.cron-scripts/analysisd_killer.sh)
2. Open a Terminal
3. crontab -e
4. Write */3 * * * * /Users/[your_username]/.cron-scripts/analysisd_killer.sh (You can change the 3 to any number of interval minutes you prefer)
5. [Optional] Above the line you just wrote, you may want to also write MAILTO="" to prevent this very frequent cron from filling up your disk space with logs in /var/mail
6. Save & quit the file and editor. (if stuck in Vim, press Esc, then type :wq and press Enter)
7. MacOS might prompt you with your terminal app wanting to make administrative changes, this is the cronjob installation, click Allow.
8. You should be good to go!

Now I have already been told that allegedly doing frequent crons like this is bad and one should use a sleeping bash process on an infinite while true loop, but I am far too lazy to set that up, and I'm not entirely convinced it matters at all, but to each their own.

Lastly, if one is really lazy or for any other reason doesn't want to bother setting up a cron, for what it may be worth, the original proposed solution in the main gist of sending a SIGSTOP signal to the process to freeze it instead of killing it seems to also be effective, at least as far as CPU and GPU hog goes, I verified with ps wuax | awk '$8 ~ "T"' to list all SIGSTOP'd processes that it remained stopped for a good while, but I did not like the uncertainty that it could eventually still randomly by unfrozen by the OS without warning, plus it requires the evil process to be running, which makes this difficult to automate on startup. As such I sought the other options found in this comment.

Possible "permanent fix" solutions for Big Sur and up

Click to view

Here is an adapted version of @ElectronHerder's solution with required changes that might make it work on Sonoma/Sequoia/+, but I have not tested this due to an apparent high risk of corrupting the system!

[!CAUTION]
The below instructions are UNTESTED, and may CORRUPT your system, requiring you to REINSTALL the OS, losing ALL YOUR DATA. Additionally even if it works it MAY BREAK OS UPDATES. I am not responsible for any damages caused by following these, I merely aggregated information from multiple different sources here.

Deactivate System Integrity Protection

1. Turn off the Mac
2. Hold down Command-R for about ten seconds and press power button
   The above instruction is for pre-M1 Macs, for M1+ Macs you should hold the power button itself for about 10 seconds. (ref: https://support.apple.com/en-us/102518#applesilicon)
3. Wait for OS X to boot into the OS X Utilities Window
   + and then select "Options" then click the "Continue" button that appears underneath.
4. Choose Utilities -> Terminal (on the top left menu bar)
5. csrutil disable
6. csrutil authenticated-root disable (See: Big Sur’s Signed System Volume)
7. reboot

Remove or rename the photo/mediaanalysisd files

1. mkdir ~/livemount
2. mount -uw / This does not work on Big Sur+, use the command below:
   sudo mount -o nobrowse -t apfs /dev/PLACEHOLDER ~/livemount (See EliteMacX86's guide to figure out what to put instead of PLACEHOLDER)
3. cd ~/livemount
4. mv -v System/Library/LaunchAgents/com.apple.photoanalysisd.plist /Users/[your_username]/Documents/Evilstuff
5. mv -v System/Library/LaunchAgents/com.apple.mediaanalysisd.plist /Users/[your_username]/Documents/Evilstuff
6. mv -v System/Library/PrivateFrameworks/PhotoAnalysis.framework/Versions/A/Support/photoanalysisd /Users/[your_username]/Documents/Evilstuff
7. mv -v System/Library/PrivateFrameworks/MediaAnalysis.framework/Versions/A/mediaanalysisd /Users/[your_username]/Documents/Evilstuff
8. sudo bless --folder ~/livemount/System/Library/CoreServices --bootefi --create-snapshot

Reactivate System Integrity Protection

1. Turn off the Mac
2. Hold down Command-R for about ten seconds and press power button
   M1+: Hold the power button for about 10 seconds.
3. Wait for OS X to boot into the OS X Utilities Window
   + and then select "Options" then click the "Continue" button that appears underneath.
4. Choose Utilities -> Terminal (on the top left menu bar)
5. csrutil authenticated-root enable (Apparently you cannot ever turn this back on if you want to preserve your changes but I'm not sure)
6. csrutil enable
7. reboot
8. Hope it works.

If you actually took the risk of following these and it works, I'd love to know, please @ me here.

Another possible alternative?: Kernel Extension

In the world of Kernel Extensions it appears they have a solution to this offered by the RestrictEvents kernel extension.

Specifically note the revblock=media option:

media - block mediaanalysisd on Ventura+ (for Metal 1 GPUs)

Unfortunately these kexts all seem geared towards Hackintosh devices, not real Macs, so it appears to be either difficult, not recommended, or impossible to install them on a real Mac, so I didn't bother any further research on them myself, but I leave the mention of this kext here should any future reader want to venture into these or already knows how to.

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