OS X Mavericks User background processes run even though user never logged in.

[tnielsen]

The title says it all, but I'm curious... is this intended? For instance, let's say I create a new user account, reboot, log into a different account than the one I just created.

I'll find that that newly created account will have 4 processes running. LaunchD, mdworker, cfprefsd and mdworker32... even though the account has never been logged in to.

Can anyone else confirm this? I understand this is totally not a JAMF issue but I thought I'd ask the guys that know their OSX.

[thoule]

Generally, a user process should not be running after logout. The mdworker process is spotlight and maybe it just hasn't died off yet. If it continues for more than a couple minutes, I suggest you look into it further.

[millersc]

I JUST opened a ticket with Apple on this problem. This appears to be a known issue as from this Apple forum thread.

https://discussions.apple.com/thread/6468254?

It's nasty when you have multiple users logging in and out.

[tnielsen]

That was my thought too. However, I started to wonder if Apple changed it around. It's very unusual for an account that has NEVER been logged into, either.

[millersc]

I have a few theories, but will try to work them out with an Apple Engineer. Right now I'd just love a work around as it's killing my school labs. Only way I've found to kill those processes off is two clean reboots from the login screen. Not even from the Apple Menu or timed shut downs.

I have seen a hard crash, reboot and many of the user accounts start processes up that are not nor have they logged in after the reboot.

I've bookmarked this thread. If I get some info, I'll be happy to pass it along.

[tnielsen]

@millersc Ok, this is semi-reliving. I was worrying that my standard image process was somehow compromised by malicious software. I looked over the system and couldn't find any signs of compromise though.

[tnielsen]

A little outloud braingstorming here....

If a launchdaemon or launchagent is set to run as that user, then I could see where launchd would get invoked that could cause a chain reaction of process executions as that user account. However, in your example... every student would need to have an agent doing this. So.. that kills that possibility.

[millersc]

@tnielsen if you look at the processes, you'll find their parent is launchd. I'm working on a script to try and kill any user process that is not the currently logged in user. Not ideal, but a work around. If I get something working, I'll share!

Also, I've been testing this against AD and standard base image. Same results. I feel this is a Maverick/Yosemite issue. I haven't spun up a 10.8 image to test it, but will when I can. Just for sanity.

[tnielsen]

I feel like I would have noticed this kind of thing before. I'm a process snoop, hate unknown processes. I would take a close look at those launchdaemons in /library for anything out of the ordinary. I just found com.apple.aelwriter.plist on this system which shouldn't be there. That software isn't installed.

[htse]

we use network home folders with Kerberos, we noticed it when when a user changes their password, our logging system starts throwing alerts about invalid passwords, even if they're logged out. cfprefsd, distnoted, continues to run, and one other process. From the best I can tell, it's an artefact related to sandboxing.

[bentoms]

@htse, fwiw.. I know when trying to workaround the local items keychain that the secd process would run creating the local items keychain.. But on a restart & not always a logout/in. Even though it's a user setting & not system.

My guess in that case, is that it's to do with the iCloud services, this could be the same for these other processes.

[tnielsen]

@htse that would make sense. It fits the situation... I still don't like those processes running under that user account without the user being logged in. Doesn't seem... smart. Going to continue testing.

[htse]

just for personal curiosity, it persists all the way up to 10.10, on a known-good system, so I've forsaken filing a bug report about it, and accepted it to just be expected behaviour for the above reasons.

[tnielsen]

This kind of behavior is rough. Careful restoring user preferences to an account that's already online. If cfprefsd is running while you copy the preferences, they will be overwritten again with the previous ones.

I wonder if there's a way to disable this behavior...

[millersc]

Just wanted to update this thread.

I've implemented a "kill" script, along with launch daemon and login hook. Little over kill, but after the hell this has put me through it's helping. So far feedback has been good in our kiosk areas. Any given logged in user is now only seeing 130 or less processes, no longer pushing upwards of 300+ at login. No other users are processing when not logged in.

We have been in communications with Apple. Waiting for more feedback.

I'm working on getting these scripts pushed to github shortly.