Here's a job control conundrum for you.

[Steven W. Orr]

On Wednesday, Apr 11th 2007 at 09:31 -0400, quoth 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

Waiting for a dead child isn't part of the equation as far as I can tell. 
I have "set -o notify" in my bashrc. Either way it makes no difference 
because without the set command, I wouldn't be told of the child death 
until the next time I hit <RET>.

BTW, it turns out that killall -1 alpine from another window *is* 
effective. So it looks like issuing a killall -1 from the window where the 
child is is part of the problem.

-- 
Time flies like the wind. Fruit flies like a banana. Stranger things have  .0.
happened but none stranger than this. Does your driver's license say Organ ..0
Donor?Black holes are where God divided by zero. Listen to me! We are all- 000
individuals! What if this weren't a hypothetical question?
steveo at syslang.net