user processes still active after logging out on 10.10

jake_snyder
New Contributor III

It looks like user processes are still active after logging out. These don't seem to clear up unless the computer is rebooted.

Will 10.10 intelligently handle clearing these processes as resources are needed, or should I figure out a way to have the computers reboot on logout?

31 REPLIES 31

millersc
Valued Contributor

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.

bpavlov
Honored Contributor

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.

nessts
Valued Contributor II

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.

millersc
Valued Contributor

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

tnielsen
Valued Contributor

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

millersc
Valued Contributor

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.

tnielsen
Valued Contributor

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

nessts
Valued Contributor II

@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.

millersc
Valued Contributor

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.

optional image ALT text

jake_snyder
New Contributor III

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?

millersc
Valued Contributor

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

jake_snyder
New Contributor III

thanks! @millersc

millersc
Valued Contributor

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

agrosvenor
New Contributor

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

jake_snyder
New Contributor III

@millersc this works great! thank you so much!

denmoff
Contributor III

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.

millersc
Valued Contributor

@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

denmoff
Contributor III

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.

agrosvenor
New Contributor

@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!

eb99a576d2644335ab653d3c19993632

millersc
Valued Contributor

@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.

millersc
Valued Contributor

@agrosvenor can you email me offline.

dferrara
Contributor II

@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.

millersc
Valued Contributor

@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.

dferrara
Contributor II

@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!

agrosvenor
New Contributor

@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. "

dferrara
Contributor II

@agrosvenor Thanks a lot for the reply. I'm trying to kill the procs that stick around from the prior users. It's really nasty, the dock gets corrupted and programs won't launch. I discovered this thread with a few more scripts I'm going to try:

https://discussions.apple.com/thread/6468254?start=15&tstart=0

Apparently this is a longstanding issue. I really don't understand why Apple fails to address massive bugs like this which affect enterprise environments.

millersc
Valued Contributor

@dferrara We had an Apple Engineer out and document the problem. Reproduced it in 10.9.x and 10.10.x. Because at that time, 10.11 was already released, 10.9 and 10.10 are only kept up for security issues only. It was determined this was a known issue internally and not resolved. I have not checked against 10.11 to see its been resolved.

Can you post up a list of the zombie processes? I'm wondering which processes are still holding out. If it's PC, which version are you using?

While we do use PC Client for our teachers, we don't use it for students. That means we don't see multiple users on teacher stations, unlike student stations. We can see upwards of 90+ users on one station which leads to these zombie processes saturating the computer.

If you want, you can email me offline.

nigelg
Contributor

@millersc @dferrara I am still seeing this issue with 10.12.6. In a lab its a nightmare - every user leaves 10 or more processes.

millersc
Valued Contributor

@nigelg do you have parental control active or isn't it limited to a handful of processes for each user? Can you share a screen shot of activity monitor?

nigelg
Contributor

b89855ba18f745ccad3ab30c7d16c20a

@millersc We do use parental controls - any info on the impact that could have would be useful. Each user ends up with these processes running when they log out and some of them (mainly mdworker - spotlight) can come back after a reboot. I am currently running a logout script to kill processes but its a bit dirty.

After running the logout script to kill processes, users are always left running trustd, lsd and cfprefsd.

millersc
Valued Contributor

@nigelg im not at my desk to show my screen shots. But this looks like it might be the parental control config profile issue. Search the forum here. I know guys have been having issues with that and 100% processor spikes