Code Block pid: 26919 first observed: 2020-11-17 13:54:20 last observed: 2020-11-17 13:54:20 program: kmutil program path: /usr/bin/kmutil signing ID: com.apple.kmutil team ID: program modification date: 2020-01-01 00:00:00 program status date: 2020-01-01 00:00:00 ppid: 1 parent program: launchd parent program path: /sbin/launchd parent signing ID: com.apple.xpc.launchd parent team ID: parent program modification date: 2020-01-01 00:00:00 parent program status date: 2020-01-01 00:00:00 FORK /sbin/launchd EXEC /usr/libexec/xpcproxy arguments: xpcproxy com.apple.applefsplaceholder EXEC /usr/bin/kmutil arguments: /usr/bin/kmutil load -b com.apple.fsplaceholder exit
Code Block pid: 26919 first observed: 2020-11-17 13:54:20 last observed: 2020-11-17 13:54:20 program: kmutil program path: /usr/bin/kmutil signing ID: com.apple.kmutil team ID: program modification date: 2020-01-01 00:00:00 program status date: 2020-01-01 00:00:00 ppid: 1 parent program: launchd parent program path: /sbin/launchd parent signing ID: com.apple.xpc.launchd parent team ID: parent program modification date: 2020-01-01 00:00:00 parent program status date: 2020-01-01 00:00:00 FORK /sbin/launchd EXEC /usr/libexec/xpcproxy arguments: xpcproxy com.apple.applefsplaceholder EXEC /usr/bin/kmutil arguments: /usr/bin/kmutil load -b com.apple.fsplaceholder exit
Hi, I've had this same issue ever since upgrading to Big Sur a month ago. Launchd fires kmutil load -b com.apple.fsplaceholder every 10 seconds, causing kernelmanagerd to be my top 2 CPU user.
The following tricks have not helped:
sudo kmutil install --check-rebuild and sudo kmutil install --update-all, which fails with: failed to build release collection: Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"sudo launchctl unload /System/Library/LaunchDaemons/com.apple.applefsplaceholder.plist, which fails: Operation not permitted while System Integrity Protection is engaged¹ I thought this would be safe mode, but is actually single-user mode, which should be disabled but in fact booted with no 3rd party kexts loaded. Safe mode (hold shift) does not work as I've forgotten my EFI password 😅
However, just once I got kernelmanagerd to quiet down by starting Dropbox.
I crudely checked that Dropbox (and VMware) have linkings against com.apple.fsplaceholder:
/Library $ sudo grep -i fsplaceholder -R .
Binary file ./Apple/System/Library/Receipts/com.apple.files.data-template.bom matches
Binary file ./DropboxHelperTools//Dropbox_u501/dbkextd matches
/Applications $ sudo grep -i fsplaceholder -R .
Binary file ./Dropbox.app/Contents/XPCServices/InfiniteProxyHelper.xpc/Contents/MacOS/InfiniteProxyHelper matches
Binary file ./Dropbox.app/Contents/XPCServices/InfiniteProxyHelper.xpc/Contents/embedded.provisionprofile matches
Binary file ./Dropbox.app/Contents/Frameworks/python-extensions/macinfinite_native.cpython-38-darwin.so matches
Binary file ./VMware Fusion.app/Contents/Library/vkd/spherelet-initrd matches
Here's my 3rd party kexts, after removing two from unidentified developers.
Attached is one round of kernelmanagerd insistently checking extensions.
BIg Sur (or was it Catalina?) REALLY changed how kexts are handled, and if you've upgraded from previous versions of MacOS it seems the system can get somewhat stuck rebuilding the current kext "collection". I'm not sure how much of my issues were just Dropbox triggering com.apple.fsplaceholder (see other comments here) but I think it's worth commenting here the other troubleshooting tools I found in case others find it useful:
kmutil log show #shows last day's kernal management activity kmutil log stream #shows current activity kmutil clear-staging #might help if you're trying to remove a 3rd party kext but it seems not to go away
And finally, what really seemed to help for me was booting into recovery and running:
kmutil trigger-panic-medic --volume-root /volumes/name-of-my-boot-drive
Once you reboot, any 3rd party kexts using the "old" system of installation will once again require you to acknowledge them in System Preferences' Security & Privacy's General tab, at the bottom. For each 3rd party extension it finds, it will ask you to "Allow" it and then reboot for it to be added back in to the next kext "collection" or whatever they call it now.
The "new" way going forward is like what Little Snitch does, where the kext is stored in the application bundle and MacOS is just told to hot-load it. I think these new ones run in user-space and thus are more crash resistant? The older ones that have to run in kernal-space no longer can be hot-loaded and must go through this collection-update and reboot process. And it's apparently even more complicated on Apple Silicon.
Hello I Fixed this by deleting them nasty smelling file:
$ ls -l /Library/Preferences/com.apple.fsplaceholder/
-rw-r--r-- 1 root wheel 0 May 21 18:43 com.dropbox.user.98ecb765c7491ca8a181eaacc2aeac1ce7fd0c4a
Restarted Dropbox, and it hasn't come back as of yet. Thanks, Dropbox..
--
I realised that /System/Library/LaunchDaemons/com.apple.applefsplaceholder.plist has:
<key>QueueDirectories</key>
<array>
<string>/Library/Preferences/com.apple.fsplaceholder</string>
</array>
…and from man launchd.plist:
QueueDirectories <array of strings> This optional key keeps the job alive as long as the directory or directories specified are not empty.
Huh 🤪
This fixed the CPU spike every 10s for me! However the file just comes back after rebooting. Any ideas on how to prevent that?
I simply deleted the directory /Library/Preferences/com.apple.fsplaceholder and created an empty file in its place to block its creation. So far that has seemed to do the trick!
Someone needs to write to dropbox to ask them why their daemons insist on creating com.dropbox.user.98ecb765c7491ca8a181eaacc2aeac1ce7fd0c4a all the time!? IMPORTANT EDIT: This does solve the excessive kernalmanagerd activity, but it also somewhat breaks SmartSync. Apparently what the com.dropbox.user... file is for has to do with the trigger that happens when you access a SmartSync "online only" file placeholder so that it automatically downloads. A better solution will need to be found.
Hi, I have the same problem with kernelmanagerd.
May I ask what kind of logs you were looking at to figure out where the problem was coming from?
Run "kmutil log show" and it will dump the last day's logs, or run "kmutil log stream" to view the current log going forward.
My problem was as some others here had, with Dropbox creating an empty file at "/Library/Preferences/com.apple.fsplaceholder/com.dropbox.user.98ecb765c7491ca8a181eaacc2aeac1ce7fd0c4a" which triggered something to run kmutil on it that does... nothing except chew up cpu and disk resources. Over less than 24 hours it had caused kernelmanagerd to run up over an hour of cpu time and 30+ GB of data read and written.
Deleting the com.dropbox.user... file would solve it temporarily until something puts it right back again. So, I deleted the com.apple.fsplaceholder directory and replaced it with an empty file. So far that has done the trick. Time will tell what else that directory is supposed to be used for and will break because of my treachery. :) EDIT: Aha. This breaks Dropbox's SmartSync. Grr.
Sorry to bring this thread from the dead... I'm having the same problem, and I can confirm what PerterJ has said. However, I contacted dropbox about the issue and hopefully they will do something about it. I have just a question, how did you create the empty file com.apple.fsplaceholder to avoid the recreation of the directory. I've created a file (with textedit) with no extension, but the folder keeps being created. How did you manage this?
Thanks,
G.
