Q: Stray processes after a user logout
-
Oct 1, 2014 2:12 PMby Georgy Karageogiev,I think you could use my script in a customized logout as described here. You may need to customize it a bit, namely to remove the check if the user has logged out.
-
Oct 1, 2014 2:20 PMby MyrkridianRhapsody,If I am reading your script right, it looks like I have to know the name of the user (or all possible users) with which the script will be run for. In my environment that is impossible. If I could run it indiscriminately at every user logout, that would probably work.
-
Oct 1, 2014 2:28 PMby Georgy Karageogiev,The documentation from the link I have posted says:
- In your script, the variable
$1returns the short name of the user who is logging in.
I'm just hoping the same applies to LogoutHook scripts. Then we only need to know if the command w returns the currently logging out user. In case it does you will need to modify the script by deleting or commenting out the three lines under the following comment:
# Make sure the user has logged out
- In your script, the variable
-
Oct 2, 2014 7:43 AMby MyrkridianRhapsody,Thanks for your help so far. So I commented out the three lines, made an executable out of it and created a logout hook for testing. It didn't appear to work; I logged into three separate accounts, and at the third one, I could still see all of the processes owned by the first two users. I tried running the script while be logged in on a user, not sure if it helps but here is the output I get:
/Library/Scripts/kill_stray_processes: line 21: : command not found
/Library/Scripts/kill_stray_processes: line 22: : command not found
/Library/Scripts/kill_stray_processes: line 27: syntax error near unexpected token `then'
/Library/Scripts/kill_stray_processes: line 27: ` if [ -f "$1" ]; then'
logout
[Process completed]
-
Oct 2, 2014 8:08 AMby Georgy Karageogiev,Something tells me you have introduced some extra characters when you have copy-pasted the script to your system or you have used some rich text editor. I have the following tips for you
- Make sure you don't have any invisible characters other than spaces, tabs and line-feeds in your script. Use a plain text editor that can display the invisible characters and make sure that the lines that start with blank characters contain only spaces or tabs in the beginning and only line-feed character at the end.
- Test the script manually. The logout hook should effectively work like the following command you can execute from the terminal (put some real user name different from the current user in the place of <some_user>) :
sudo /Library/Scripts/kill_stray_processes <some_user>
- You can make visible the flow of the script commands for easier debugging. Change the first line as follows (and don't forget to change back when you go on production):
#!/bin/bash -x
-
Oct 2, 2014 8:23 AMby MyrkridianRhapsody,I'll check your script again. I just made a little script to run
sudo pkill -9 -fx com.IconServicesAgent
and at least that seems to be working. I figured since that is the largest process and taking up the most memory, that may be enough to fix the issue of machines becoming unresponsive. I will test your script in the way you suggested here in a bit.
-
Oct 14, 2014 7:26 AMby JKersten,I'm having the same problem in the public labs I manage running Mavericks (Yosemite has the same issue, BTW). I tried modifying Georgy's script to run as a login hook but I never could get this approach to work reliably. For starters, if the script kills the user's loginwindow process, it will self-terminate (along with most other user processes) before it's finished, possibly leaving you worse off than before. It's relatively trivial to modify the script to not do this, but I still couldn't get it to behave consistently, probably due to timing issues.
In our environment, we use AD logins, but not roaming homedirs. Homedirs are created at login and periodically cleaned. Because of this, we can simply look at the contents of the /Users directory to determine which users might need to be terminated. The following script won't win any awards for efficiency, but it gets the job done. The script will skip users who are actually logged in when it executes. I can run this manually via ARD (hence the ech statements), but also have it set up as a launchdaemon to run periodically.
I still end up with cfprefsd processes for old users, but this is because something is relaunching them after they are killed (probably the "system" cprefsd instance).
#!/bin/bash
for DIR in $(ls /Users); do
if [ $DIR != 'Shared' -a $DIR != '.localized' ]; then
SKIP="no";
for USER in $(users); do
if [ $DIR == $USER ]; then
SKIP="yes";
fi;
done;
if [[ $SKIP = "yes" ]]; then
echo "User $USER is actually logged in"
else
pkill -9 -u $DIR;
echo "User $DIR has been staked";
fi;
fi;
done;
-
Oct 14, 2014 8:12 AMby MyrkridianRhapsody,I was going nuts over this issue. Apple returned the bug submission with the reply:
"XPC services will only be killed if the system needs to reclaim the resources for some other process."Which is obviously not happening, because the process are crashing my computers. I washed my hands of it and downgraded them to Mountain Lion. Everything is back to working properly now. I didn't want to downgrade, particularly because of SMB2 incompatibilities of pre-Mavericks OSes. But I am done caring about this issue for now.
-
Oct 22, 2015 2:32 PMby JonathanCross,I'm using this to manually kill the zombie user processes in El Capitan:
function kill_zombie () {
ZOMBIE_USER=sam
PROCS=$(ps -u $ZOMBIE_USER | awk '/[0-9]/ {print $2}')
echo "Active processes for $ZOMBIE_USER: $($PROCS | wc -l)"
for P in ${PROCS[@]};do
printf " $P: ";
sudo kill -kill $P && echo " - OK";
done
echo "Remaining:"
ps -u $ZOMBIE_USER | awk '/[0-9]/ {print $2}'
}
