Apple Event: May 7th at 7 am PT
I just wonder why this item is using over 80% of my CPU. I have no idea what this application do. I would be grateful if somone could explain for me. I am hesitant to fidle with system items such a remove it. It is in the System Folder under Core Services.
Thank you
Innocents
Mac Pro, OS X Mavericks (10.9.5), FCPX 10.1.3, Mavericks 10.9.5
It gets worse.
Take a look at the memory usage for that service. You may find that it keeps sucking down the RAM.
That's the problem I had. After running for about 6 hours, the service was using 20 GB (yes, GB) of virtual memory, and making the system virtually unusable. In fact, I had to do a hard reboot once since the system wasn't responding at all.
After doing a search of other posts, I found the problem (at least for me). Right-click on any folder in the Finder, and select "Folder Actions Setup...". A dialog will display to select a script to attach to the folder. Just hit Cancel, and you'll be left with a dialog showing what existing folder actions you have set up.
I had several scripts set up on various .../LaunchAgents and .../LaunchDaemons folders. I'm not sure when I did that, but it was probably years ago in an attempt to be notified if some malware attempted to install bad daemons or agents on my system (probably something I read in article somewhere). It looks like there's a problem with Yosemite wherein the service that monitors those things goes a bit wild.
My solution was to simply either uncheck the "Enable Folder Actions" checkbox, and/or delete all of the existing folder actions. That completely solved my problem. No more CPU hog, and more importantly, no more RAM hog. System is humming along just fine.
Let me know how it goes. I'm curious as to whether this is the same problem I was experiencing.
DragonDave wrote:
...I didn't "fix" things by letting it run over the weekend. That was to simply test that the update to 10.10.2 actually fixed the issue I was seeing.
😊 OK, I understand! I'm doing basically the same thing, i just didn't have a weekend during this week! 😝 In truth, the Installer did tell me about several items that are 'incompatible', one that I've updated. But I also found one prefPane that it didn't report.
I've re-installed several of the Services that I disabled. Frankly, I think that is a completely different concern and not relevant to the 'Dispatcher' problem. I sometimes create more problems than I 'fix'! 😮
My plan for today is to restore some of the items in the 'WatchPaths' list in FolderActions.plist.
What I would dearly love to know is which folders actually have a Folder Action assigned/applied to them. Right now, opening Folder Actions Setup gives me a "System Events" crash! I then can get the 'Dispatcher' crash by clicking the "Enable" checkbox. 😠 Frankly, I don't even know what Folder Actions might be in use, I don't remember ever adding one, although I had some apps that did notify me when a '(not sure which one) daemon' folder had changes made to it. Oh well, slowly moving forward... Hope this weekend is as good for you as the last one! 🙂
I'd also like to throw this out there on the off chance it might help someone. It applies to old apps you might have that make use of services or agents (i.e. non-UI processes) that get started when you login or when the system starts up.
OS X was making use of a technology called "StartupItems". Let's say an application needed to start a process up when the system booted. It would place a plist file (plus the process itself) in /Library/StartupItems (or in /System/Library/StartupItems, or in ~/Library/StartupItems). When the system booted (or you logged in), the OS would look in that directory for any plist files, and start up the process referenced by the plist file.
Apple has deprecated that technology for the last several years, in favor of a technology that uses a process called launchd. Launchd is a more modern way of managing those types of processes, and they use files in different folders (e.g. /Library/LaunchAgents). When I say "deprecated" I mean that Apple was giving fair notice that the use of StartupItems wouldn't last forever.
Well, when Yosemite came out the hammer fell, and the use of StartupItems was turned off completely. That means that any app that made use of StartupItems wouldn't work correctly. Hopefully, the developer would have corrected the issue long ago and started to use launchd, but you never know. I had one case of that issue occurring, and the developer came out with a fix soon after Yosemite was released (had to do with licensing).
Anyway, I thought I'd mention it. If you look in those StartupItems folders and see files in there, they're not being run as they should (of course, it could just be old crap that's been sitting around for a long time).
I may have found which folders might have folder actions assigned. ~/Library/com.apple.FolderActionsSetup.plist shows two different items. One is a list of X, Y, Height, and Width for DefaultFolderX:NSOpenPanel values. This may actually be used that app to open it's own navigation window, instead of the System nav window. That app is behaving normally and the developer noted that the last update of the app was to fix a bug in Yosemite that was causing System Nav windows to grow by 22 pixels with each new display of one.
The other, however item refers to a folder. Its path and values for "NSNavPanelExpandedSizeForOpenMode".
The problems I'm having with Folder Actions Setup may be caused by the fact that I have deleted the folder (CaptureIt) being referred to? On my mini (running Yosemite), that plist has only
in that <dict>. I may edit that, at least to remove the deleted folder. What could possibly go wrong?! 😝
Would anyone be so kind as to look at the ~/Library/Preferences/com.apple.FolderActions.plist? Note, this is not the com.apple.FolderActionsSetup.plist.
On my mini, it has exactly two <key> items in its <dictionary> now. I used Folder Actions Setup app to enable folder actions so a second <key> item has been added to what is shown in my previous post. The second <key> item is "folderActionsEnabled" with a value of <true/>.
On my iMac, that same plist has 15 entries! They are almost all duplicates, actually defined in <key> labels in the 15 <dict> items as aliases! I have no idea how they were created, much less why. I plan on deleting every last one of them and observing how the Folder Set Up app behaves.
BTW, when ever editing plists, it's a good idea to make a copy of the original and store it safely outside the appropriate directory. Many plists are editable in any text editor, however, these two FolderAction plists are in binary, so I'm using Xcode.
Later...
PROGRESS!!! 🙂 I am now able to open Folder Actions Setup without any crashing! Even shows a list of available folder actions, allows me to enable or disable folder actions! Just like a Mac is supposed to operate! 😮
Since folder actions are disabled, I notice that all the WatchPaths in com.apple.FolderActions.folders.plist are gone! And ~/Library/Preferences/com.apple.FolderActions.plist now responds to whatever the checkbox in Folder Actions Setup show (checked/enabled or unchecked/disabled).
Success? [we need a 'fingers-crossed' smilie]
Thanks for the help and ideas here! 🙂
THANKS DragonDave! It worked for me as well. A real rescue. 🙂
Folder Actions Dispatcher.app using 80% CPU
