BASH script won't die when user logs out.

arizonagroovejet · 11-03-2009, 06:00 AM

I've got a BASH script which runs when a user logs in. When a user logs out the script keeps on running. Which is Bad. I'm wondering if anyone can explain how to make the script die when a user logs out.

I've considered making the script check if the user is still logged in by looking at the output of 'who' but had to scrap that when I discovered that a user logged in via an NX session doesn't show up in the output of 'who'. (Whole other issue.) Also that would just be a workaround to the problem rather than a solution.

The script gets run when GNOME starts like this:

Code:

foo:~ # cat /usr/share/gnome/autostart/why_wont_you_die.desktop 
[Desktop Entry]
Type=Application
Name=Test script
Comment=Test script
Exec=/usr/local/sbin/why_wont_you_die

I've tried redirecting stdout/stderr to /dev/null and closing stdin by appending >&- to the end of the Exec line but none of that helped.

The script shows up in the output of pstree like this:

Code:

     ├─gdm───gdm─┬─X
     │           └─gnome-session─┬─bluetooth-apple
     │                           ├─compiz-manager───compiz───gtk-window-deco
     │                           ├─gnome-do───3*[{gnome-do}]
     │                           ├─gnome-keyring-d
     │                           ├─gnome-panel
     │                           ├─gpg-agent
     │                           ├─nautilus
     │                           ├─pidgin
     │                           ├─python
     │                           ├─python─┬─3*[bash]
     │                           │        ├─gnome-pty-helpe
     │                           │        └─{python}
     │                           ├─why_wont_you_di───sleep

The script itself looks like this:

Code:

#!/bin/bash

while true; do
sleep 600
date > /dev/null
done

I wonder if the problem is related to the use of the while true loop though the script exits fine if I use 'kill PID' from the command line.

N.B. this is not actually the script I'm having trouble with as that's rather long, it's a nice short script which does essentially the same thing (sleep for a while and then do something, all wrapped in a while true loop) that demonstrates the problem I'm having.

kbp · 11-03-2009, 07:51 AM

Try putting it under '~/.config/autostart' ... should do the job

cheers

arizonagroovejet · 11-03-2009, 08:31 AM

Unfortunately putting it in ~/.config or ~/anything is no good. I have thousands of users who could log in to the machines. Modifying all their home directories would be madness.

(Also for technical reasons I can't actually do that myself.) I need to start the script from a system wide directory. I tried using /etc/xdg/autostart but that makes no difference.

tredegar · 11-03-2009, 09:15 AM

Which user is the script running as?
ps -Al | grep why_wont_you_die will return the user's UID as the third field.

arizonagroovejet · 11-03-2009, 10:00 AM

The script runs as the same user that ran the GNOME session which invoked it.

kbp · 11-03-2009, 03:38 PM

Maybe you need to trap signals, this may help:
http://www.linuxquestions.org/questi...m-bash-257157/

cheers

arizonagroovejet · 11-04-2009, 04:34 AM

I've tried trapping various combinations of TERM INT and EXIT like so:

Code:

#!/bin/bash

trap "{ touch /tmp/blah; exit 0; }"  TERM INT EXIT

while true; do
sleep 600
date > /dev/null
done

It doesn't make any difference.

I know the trap syntax is good because if I include INT, run the script from a command prompt then press ctrl-c the time stamp on /tmp/blah gets changed.

evo2 · 11-04-2009, 04:41 AM

Hi,

I've come up against a similar problem before. What I think might be happening is that the sleep subprocces is not being killed. As suggested by another poster I tried to implement a trap to kill it, but couldn't get it to work. What might work for you is to replace the loop with a recursive call of the script. In this case your example would become:

Code:

#!/bin/bash
sleep 600
date > /dev/null
exec $0

Evo2.

evo2 · 11-04-2009, 04:55 AM

Hm,
stupid me. My recursive script won't work. Please try the following trap. I should kill the whole process group (ie including the sleep) when the parent script is killed. The key here is the minus sign in front of the pid. The -- is needed so that kill does not interpret it a switch.

Code:

#!/bin/bash

trap "/bin/kill -- -$$" EXIT

while true; do
sleep 600
date > /dev/null
done

Evo2.

arizonagroovejet · 11-04-2009, 05:46 AM

I tried 'trap "/bin/kill -- -$$" EXIT'. No effect. I also tried adding TERM INT and HUP to the list of things to catch just for the hell of it.

Then I tried a slightly different method of doing the same thing:

Code:

#!/bin/bash
trap "touch /tmp/blah ; pkill -P $$; exit 0" EXIT TERM INT HUP

while true;do
sleep 600
date > /dev/null
done

That doesn't work either. Also /tmp/blah doesn't get touched. It does get touched if I manual kill the process after log out using 'kill PID'. This leads me to wonder if maybe the problem is that when the GNOME session ends the script just isn't being sent any of EXIT TERM INT HUP. Though why that should be or what it could be being sent instead I have no idea.

evo2 · 11-04-2009, 06:07 AM

Hmm,

how about using a slightly different approach. Perhaps you could used gdm to start and stop your script.

http://library.gnome.org/admin/gdm/s...l.en#scripting

Evo2.

arizonagroovejet · 11-04-2009, 06:23 AM

Right now I am using the GDM PostSesssion script to clean up the problem script after a user logs out. However if a user logs in with NX then GDM isn't used, so the script keeps running when user logs out. I can do something with NX to clean the script up as I've done for GDM, but that's just adding in another work around. Rather than keep adding workarounds, I'd really like to solve the problem of why the script doesn't get killed when the GNOME session ends. All the other children of the gnome-session process get killed, yet my script doesn't.

arizonagroovejet · 11-05-2009, 10:36 AM

I think I've come up with an acceptable solution. It's a workaround, which is irritating, but it's a workaround contained in the script itself rather than one that relies upon another script, such as a GDM session script.

Code:

#!/bin/bash

parentpid=$PPID

while true;do

sleep 600

date > /dev/null

# check if original parent process is still running. 
# if not, exit.
if [ ! -d /proc/$parentpid ];then
   exit 0;
fi


done

The script still does not get killed when the user logs out as, IMO, it really should be, however it does exit of it's own accord within 600 seconds (or whatever value is given to sleep) of the user logging out.

kbp · 11-05-2009, 06:55 PM

Won't they actually be directories not files ? ... maybe '-d' instead of '-f'

cheers

arizonagroovejet · 11-06-2009, 02:37 AM

Doh. Yeah of course they're directories, not files. I did actually know that despite the evidence to the contrary

Thanks for pointing it out. With -f the script would die after 600 seconds even if the original parent process was still running. In testing I was logging in then out again within the 600 seconds and hence my error didn't show up. I've edited the script in my previous post to avoid someone else possibly copy/pasting a non-working version.

I'm sure the script will work properly with the -d but I'll test it later on when I have time just to make sure