No. This is a known issue in all versions of Mavericks. I've seen it in all versions of 10.10. I have not tested .4 as it dropped last night. Apple is not fixing in previous versions and unknown if they plan on fixing 10.10 since 10.11 is in dev right now. Maybe it will be fixed then, but I won't be holding my breathe.

I've had to write a kill process because of shared workstations we have. It's working on Mavericks, we don't have 10.10.x on any shared workstations as of yet, but the kill process should work.

Has this been reported to Apple? Are either of you in the dev program and testing 10.11? Now is really the time to mention this so Apple is aware and can fix it before 10.11's release. Just waiting and hoping isn't going to solve anything if they aren't aware and it hasn't been reported.

cfprefsd is one of those processes that does not die when you logout, is it a big deal that user processes have not died. What processes are you concerned about? you could just add a killall -u username in a logout hook/script if you need everything quit.

I had Apple Engineering on-site and has been reported to development.

I think this was intentional, to be honest. Take a look at which processes are still running. It's all the social media processes.

In a kiosk/shared environment, this causes problems. I've seen up wards of 100+ user accounts all running 4+ processes. This literally stops the computer in it's tracks.

Apple Engineer acknowledge this was not suppose to happen this way and opened a radar ticket with Development, but as he explained it to me, once opened he loses tracking of the ticket. Didn't expect anything to be done quickly.

If this wasn't intentional then it's a huge failure that isn't very "apple like".

@tnielsen what are you comparing this to? to say its not very Apple like? Seems pretty standard for the last 4 or 5 years. If it does not impact 95-99% of their users so its not a very high priority. They have been adding so many new features you can expect some standard stuff to get missed in the mad rush of testing cycles they must have going on there.

This was just a sampling from a fresh booted up lab computer running 10.9.3. Replicated through all the OS's.

Engineer acknowledge this should not be happening. A User and appropriate daemons should be running. This is just showing the User processes. The daemons are not showing on screen.

I believe QC has fallen off over the last few OS's. We've all felt the pain of that.

I'm concerned about the user processes adding up in our computer labs. Multiple students log in and log out throughout the day.

How would I write the killall -u username script to kill processes for all users?

@jake.snyder Give me the weekend. I'll get the scripts loaded on Github and link back here for everyone. Middle of summer rollouts.

thanks! @millersc

@jake.snyder here is the Github script. It's basic but works. Let me know if I can help.

@millersc Thank you! From my first few tests, that script works perfectly; haven't found any ill-effects. You rock.

@millersc this works great! thank you so much!

How are you implementing this script? It's not working as a logout script for me. I'm still ending up with two or three processes remaining.

@denmoff I've implemented it as a three parts.

1. The script itself
2. Setting a login hook
3. Launch Daemon timed to run every 10 mins. (Run at launch)

Yes, it's over kill, but if any rogue apps start running from another user, the daemon takes care of it. At login, anything left over from someone's logout will be taken care of.

I've packaged it all up in one policy pushing a DMG because of FUT/FEU. Forcing a reboot making sure the login hook is taking and works on the next reboot. Also gets the daemon running.

I can add the Launch Daemon and command line for login hook to github if it would help.

Steve

Thanks @millersc

I've found that if i have my logout script call another script as a background process, it will kill all of the user's processes. Only issue is that i have to have the secondary script sleep for 15 seconds or else it won't get all of the processes. So the login window will be available during those 15 seconds which could be an issue if that same user decides to log back in right away.

@millersc

I've found processes still running after a user logs out and curious if you could help shed some light for us. We seem to be have an issue (I believe due to the cfprefsd process) where our students are experiencing cross-charging on their PaperCut accounts & I'm finding alternate user processes running when this happens.

Checking our script log, it appears to complete successfully (exit code: 0) but I also get a line that says (screenshot attached)

Script result: /Library/Application Support/JAMF/tmp/kill-stray-processes: line 9: kill: PID: arguments must be process or job IDs

I have very little for scripting experiencing; any assistance you can offer to point me in the right direction is much appreciated!

@agrosvenor you seem to have run into something new with this one. We are just now getting the PaperCut client rolling out. From what I can see with it, it's a LaunchAgent with a "keep alive" key.

We don't use this for our Student population but give me a short bit. I'll see if we can't do an unload for this guy.

@agrosvenor can you email me offline.

@millersc Thank you for posting your script... have you seen this issue corrupting the icon cache database? I have dozens of lab computers that are losing their icons, and it was only today that I noticed the runaway processes.

@dferrara No, I can't say I have. The icon cache db was another thought given to us by the apple engineering team, but it never helped. Using the sledge hammer approach here worked for us. Still working very well. I'm seeing upwards of 90+ user accounts on iMacs and happy users still.

@agrosvenor Hi guys, can you share whatever you discovered? We are also using PaperCut and I'm having the same issue with @millersc's script and error:

line 10: kill: PID: arguments must be process or job IDs

I have over 500 processes running with 1 user logged in and I'd love to kill them all.

Thanks!

@dferrara

We ended up using a policy that uses a script to reboot the computer when it is told to logout. We had a stickler process that the killall script was not taking care of between users. So far, while the reboot takes an extra 45 seconds during a lab turnover; it's solved our troubles with PaperCut.

Are you trying to kill processes of a user while that user is logged in; or for prior users of the computer that hang around?

Here's a little info about that error I received from millersc when I was working with it: "As for the line 9 error still. You will always get that as I get it, even on root account. That's what made making and testing and troubleshooting this take so much time. I had to actually let the LaunchDaemon do it's job in a timed configuration. So during testing I reduced it to 2 mins and worked my way through the problems. Kill -9 if you google it, is something most don't like to play with. Have you tried adjusting the LD to 2 minutes and then do a couple login/logouts with different user accounts to make it act like a kiosk station. Then let it sit the full 2 mins or so with Activity Monitor running. You should see processes fall off. "