Here's a job control conundrum for you.

[Bill Freeman]

Steven W. Orr writes:
 > On Tuesday, Apr 10th 2007 at 16:35 -0400, quoth Steven W. Orr:
 > 
 > =>I go to work in the morning and ssh in to my 'puter at home. I run alpine
 > =>which is my preferred text mail interface.
 > =>
 > =>At the end of the day I don't want to cleanly exit from alpine (for reasons
 > =>that are not important). Instead I want to kill it.
 > =>
 > =>I ^Z out of alpine so I have a stopped job. Here's where it gets interesting:
 > =>
 > =>If I say killall -1 alpine there's no effect.
 > =>If I say kill -1 %1 it does what I want.
 > =>
 > =>Anyone understand this?
 > 
 > My apologies. I confused more people than I intended. I think this is a 
 > question about the mechanics of signal delivery and not so much about 
 > which kill command I'm using or what process I'm killing.
 > 
 > I'm using the bash builtin kill command and the killall command from 
 > psmisc. If I say
 > killall -9 alpine
 > then it dies. No problem. If I say
 > kill -1 %1
 > it dies also. The question I have is why
 > killall -1 alpine
 > does NOT work. Obviously, since the killall does work with SIGKILL then 
 > killall is succeeding at delivering the signal. The HUP therefore must 
 > also be successfully getting delivered by killall, but the process 
 > (alpine) is not handling the signal in the same way.
 > 
 > AFAIK, there's not supposed to be any difference in semantics dependant on 
 > whether the sender of the signal is in the same process group. (I only 
 > mention this because I can't think of anything else.) And yes I am aware 
 > of the difference in the kill command between Bourne and C shell flavoured 
 > shells. I am using bash, though in this case it shouldn't make any 
 > difference.

Perhaps it is getting the signal, but must have its status waited for
before final exit.  With it in the background, but its parent shell
still around, it hasn't been inherited by init.  (See the fg after
killall in Ben's post???)  When you kill it with kill, since the shell
is doing it, perhaps it knows to wait for the status, allowing the
exit to complete.  Try leaving it foregrounded and killall it from
another terminal?

Bill