[comp.sys.hp] KSH job immortality...

pbm@hpfcdc.HP.COM (Peter McLain) (02/02/90)

> I have a problem with ksh and the action that is taken when
> the parent process logs out...

> ps -ef | grep burzio lists:

>   burzio 16561 16560  0 09:47:33 ttyp3    0:01 -ksh [ksh]
>   burzio 16595 16561  7 09:49:49 ttyp3    0:00 ps -ef
>   burzio 16594 16593  0 09:49:36 ttyp3    0:00 sleep 30	<-<<
>   burzio 16593 16561  0 09:49:36 ttyp3    0:00 stay stay	<-<<
>   burzio 16596 16561  1 09:49:49 ttyp3    0:00 grep burzio


> The stay shell script background procedure is still there, but
> reassigned to root to survive.  I had always thought that after
> the parent logs out, a process that has not been nohup'ped should
> die a grisly death.  What is wrong with my assumptions?

  There are a few things to think about:
     A)  what the shell does when it exits
     B)  what the system will do when the shell exits
 
  When the monitor option to ksh is turned on (a feature not available
  on the S300 before 6.5), then any job ksh runs is put in a separate
  process group.  If the monitor option is off (or on non job control
  versions of HP-UX), then all jobs are run in the same process group
  as ksh.

 A)  What the shell does
     When ksh goes through its exit code, it checks to see if either:
         a)   it is exiting because it got a SIGHUP
         b)   it is an interactive shell and its parent is init (pid 1)
     If either case holds, ksh will send a SIGHUP (and if the job is stopped,
     a SIGCONT) to the process group associated with each job that is 
     currently running or stopped.

     In your ps listing above, your login shell's parent is not init (I 
     assume it is something like hpterm, rlogind, telnetd,...) so case b
     does not hold and since your are (presumably) exiting normally, case
     a does not hold either.  So ksh will not try to kill your running jobs.

 B)  What the system does when the shell exits (see the exit(2) man page)
     Among the consequences of exiting are the following:

        1.  The surviving children of the process get inherited by init
	2.  If the process id == tty process group == process group, then
	    SIGHUP is sent to all the process in the process group of the
	    exiting process.
	3.  If the process had any stopped children, they are sent a SIGHUP
	    and a SIGCONT.

     Job control was turned on in 6.5 for the S300.  This means that ksh
     is in its own process group (pid == pgrp) and when it is not running
     a foreground job, the process group of the tty == ksh's process group.
     So when ksh exits (normally), #2 above holds.  If you have the monitor
     option turned on in ksh ("set -m" or "set -o monitor"), then NONE of
     the jobs you may have running in the background are in ksh's process 
     group, so the system will NOT send them a SIGHUP.  If the monitor option
     is turned off in ksh ("set +m" or "set +o monitor"), then all jobs 
     are run in the same process group as ksh so they WILL be sent a SIGHUP
     when the shell exits.  In pre 6.5 days, there was no job control in
     ksh so all the jobs you ran were in the same process group as ksh, #2 
     held, so any remaining jobs were sent the SIGHUP.  If there are any
     stopped jobs (e.g., you have done a "stty tostop" and you put something 
     in the background that writes to the tty), then the system will kill 
     them if ksh doesn't (#3).
 

     I think your choices for 6.5 are:
	1.  Don't ignore the running/stopped jobs messages. Kill them by
	    hand before you log out.
	2.  (Pretty gross) turn off monitor in ksh before you launch 
	    the jobs.
	3.  (Really gross) exit via "kill -HUP $$".


     Hope this explanation helps,

		Peter McLain	pbm%hpfclg@hplabs.hp.com