On Sun, 2003-10-05 at 04:10, Dieter Kroemer wrote:
> Am Sonntag, 5. Oktober 2003 02:54 schrieb [EMAIL PROTECTED]:
> > It's NOT ltsp's fault.  IT's  GDM that is buggy and doesn't kill
> > processes when the user disconnects.

Here's my workaround.  It looks for procs that meet two criteria:
1) Belong the $USER
2) Are not attached to a tty or pty

It sends each of these processes a SIGHUP (ie, "please exit now), waits
a bit, then looks the procs again.  If they are still around, it sends
them SIGKILL, which should cause the kernel to end them.  It then waits
a bit, and if they are STILL there then it sends a warning to syslog.

INSTALLATION
Add "/usr/local/sbin/gdmCleanup" to /etc/X11/gdm/PostSession/Default.

Put this script in /usr/local/sbin/gdmCleanup:
#!/bin/sh
# Copyright, 2003 Little Bald Consulting, LLC   littlebald.com
# This script is released under the GPL; you can see the terms
# of this license at http://www.gnu.org/licenses/gpl.txt.
#
# As our X session ends, clean up anything we might have left behind.
# See the end of the file for comments.
PATH=/usr/bin/X11:/usr/X11R6/bin:/opt/X11R6/bin:$PATH
WAIT=1000                                       # 1,000,000 is 1 second
                                                                                
PIDS=`ps -eo user,pid,tty | grep ^$USER | grep \?$ | cut -c10-15`
  [ -z $PIDS ] && exit 0                        # If PIDS is empty,
quit.
  ps -aef | grep ^$USER | logger -s -p local1.info -t gdmCleanup # Send
to log
 kill -1 $PIDS                                   # then signal them to
exit.
usleep $WAIT                                    # Wait, then check
again.
                                                                                
PIDS=`ps -eo user,pid,tty | grep ^$USER | grep \?$ | cut -c10-15`
  [ -z $PIDS ] && exit 0                        # If PIDS is empty,
quit.
usleep $WAIT                                    # Wait, then check
again.
                                                                                
PIDS=`ps -eo user,pid,tty | grep ^$USER | grep \?$ | cut -c10-15`
  [ -z $PIDS ] && exit 0                        # If PIDS is empty,
quit.
  ps -aef | grep ^$USER | logger -s -p local1.info -t gdmCleanup2
  kill -9 $PIDS                                 # This time, zap 'em.
usleep $WAIT                                    # Wait, then check
again.
                                                                                
PIDS=`ps -eo user,pid,tty | grep ^$USER | grep \?$ | cut -c10-15`
  [ -z $PIDS ] && exit 0                        # If PIDS is empty,
quit.
# Still here?  Something's wrong.  Warn the admin.
  ps -aef | grep ^$USER | logger -s -p local1.warn -t gdmCleanup3
exit 0

###################### END OF SCRIPT, HERE ARE THE COMMENTS
#
#  HOW THIS WORKS
# One line is key to this.  Here it is:
#     PIDS=`ps -eo user,pid,tty | grep ^$USER | grep \?$ | cut -c10-15`
# "ps -eo user,pid,tty" lists user, Process ID, and TTY for all
processes
# "grep ^$USER" drops any that don't belong to $USER.
# "grep \?$" drops any that are attached to a terminal so we don't
#                                         kill telnet or ssh sessions.
# "cut -c10-15" trims out everything but the Process ID.
# All that leaves us a list of process IDs that shouldn't be here.
# If the list is empty, we're done and we quit.
                                                                                
# If it isn't empty, we send a list of the processes to the system log
# (so the admin can see what's going on) and then send HUP (hangup)
signals
# to the processes.
# Then we wait a bit so they have time to exit neatly.
# Then we collect a new list of pids.  If it's empty, we quit.
# If not, we wait again.
# If they're still here after that, we get meaner.  We send another list
# of processes to the system log, then we send them KILL signals.  The
# kernel is supposed to rip them out by the roots, but sometimes this
fails,
# so we wait again to see.
# If any processes are left after the KILL signal, we send a warning to
# the admin.  Then we quit; there's no point waiting any longer.





-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise 
Linux in the Boardroom; in the Front Office; & in the Server Room 
http://www.enterpriselinuxforum.com
_____________________________________________________________________
Ltsp-discuss mailing list.   To un-subscribe, or change prefs, goto:
      https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help,   try #ltsp channel on irc.freenode.net

Reply via email to