I upgraded to mountain lion and was looking through the activity monitor and noticed that for all users on my system, those processes were running even though there was only one user logged in. Does anyone know why these deamons would be running for users not logged in?
Mac Pro, Mac OS X (10.5.6)
I have this same issue in Mountain Lion. The other user isn't even logged in. What's up with that?
Since upgrading to Mountain Lion, I have set of launchd processes for EVERY user account on my machine even tho I'm the only account (jakec) that EVER logs in:
-+= 00001 root /sbin/launchd
|
|-+= 00656 jakec /sbin/launchd
| |--= 00659 jakec /usr/sbin/distnoted agent
| |--= 00661 jakec /usr/sbin/cfprefsd agent
|
|-+= 00663 _spotlight /sbin/launchd
| |--= 00666 _spotlight /usr/sbin/distnoted agent
| +--= 50423 _spotlight /usr/sbin/cfprefsd agent
|
|-+= 01163 anybody /sbin/launchd
| |--= 01173 anybody /usr/sbin/distnoted agent
| +--= 50421 anybody /usr/sbin/cfprefsd agent
|
|--= 50424 root /usr/sbin/cfprefsd daemon
|
|-+= 61432 _windowserver /sbin/launchd
| +--= 61434 _windowserver /usr/sbin/cfprefsd agent
|
|-+= 63634 sysadmin /sbin/launchd
| |--= 63645 sysadmin /usr/sbin/distnoted agent
| +--= 63651 sysadmin /usr/sbin/cfprefsd agent
|
|-+= 63635 art /sbin/launchd
| |--= 63646 art /usr/sbin/distnoted agent
| +--= 63650 art /usr/sbin/cfprefsd agent
|
|-+= 63636 jakec2 /sbin/launchd
| |--= 63644 jakec2 /usr/sbin/distnoted agent
| +--= 63649 jakec2 /usr/sbin/cfprefsd agent
|
|-+= 88020 _lp /sbin/launchd
| +--= 88026 _lp /usr/sbin/cfprefsd agent
That's nearly 20 processes that do NOT need to be running.
I've looked thru each account's launch agents/daemons to see if I could disable them, but it looks like they get started by system agents/daemons, and frankly, I'm not that adventurous to see which system launch agents/daemons I can disable without causing system malfunction.
--Jake Coughlin
(coughlin.jake@gmail.com)
Same here! Anyone tried contacting Apple support?
I just noticed this, also. Upgraded to ML (10.8.2) a month or so ago. Did anyone ever find out why this is happening? I also noticed that the PID sequence seemed to be out of whack, with all of these in the 7000-8000 range, which seems well after the computer was rebooted.... Is there any way to tell when these processes started?
I have never come across a solution to this issue, but if anyone DOES know how to disable these processes for accounts that aren't used (most of which on my machine don't have an Apple ID either), I'd LOVE to know how to do it.
I think this is normal behaviour in ML. Nothing to worry about.
You can't get rid of them, so don't use kill or killall to do so, they'll just relaunch themselves as they do sometimes do something if that user should log in. For now consider it a bug in Mountain Lion. That's the way I'm treating it (along with other elements of their "do it yourself" memory manager style in Mountain Lion that cause problems) until Apple fixes it. Right now the hoops you have to go through to do so are narrow, and the price of an error is an unstable system. Don't EVER go mucking about in the command shell unless you know precisely what you're doing.
However, if those users DO show up it means they HAVE logged in recently, at the console or remotely, and moved files around. So if you see those users showing up beware, in some measure they HAVE been active, and if you've left Remote Management on and one is an administrator account, you may have an entirely different issue to worry about. The number one way to crack a Mac online is by password guessing, and weak passwords, particularly for obvious account names (never EVER have an account named "Admin" on your Mac), is your primary security threat if you allow such access.
If you kill such a job you know where they are coming from: com.apple.launchd.peruser.<userID>
I did some googling about com.apple.launchd.peruser jobs.
A "sudo launchctl list" on the server show there are a lot of these entries.
On my server there are a lot of files, and I saw mdworker processes taking quite a bit of CPU on the server and more important, they were taking a lot of througput away from my slow Drobo disks.
I presume that the server is using mdworker to index the files per user, even when those users are not logged in, using the credentials of those users probably simplifies that process.
Disabling the spotlight indexing on the server for everything but applications and folders, and putting some backup disks in the exception list, and removing access for users for folders where they are not really working in, calmed down the mdworker process immediately.
The cfprefsd and distnoted processes per user are probably the basic toolbox for this mdworker mechanism. Again, I presume the distnoted process subscribes on file system change notifications and drives the mdworker process per user.
Just my 5 cents.
It's probably the Push Notifacations daemon for the notifacations panel and for messages. Even though those users aren't logged in they still need to capture events such as photo stream updates for those users. If they didn't then when they did log in a backlog of updates, photos and notifacations would flood the network connection at login. Imagine explaining that behaivoir to a novice user. It's better to allow them to run as background tasks for all users and process the data a little at a time, than cause bottlenecks and data jams.
why are cfprefsd launched distnoted running for all users?
