Here's a job control conundrum for you.

[Ben Scott]

On 4/11/07, Steven W. Orr <steveo at syslang.net> wrote:
> BTW, it turns out that killall -1 alpine from another window *is*
> effective.

  That almost sounds like killall is refusing to send the signal to
your process group as a "safety measure" kind of thing, i.e., don't
let the user kill himself.  The thing is, I've killed myself with
killall before, so that's not consistent.  Hrmmmm.

> The --verbose shows that the kill(2) call did in fact not fail and that
> the process was delivered.

  So much for that theory.

  Hmmm, one correction, though: That shows the signal was *sent*.  You
need to use "--wait" to have killall wait and tell you if/when the
signal was *received*.

[various interesting commands]
> The fg then only prints out the name of the process but nothing happens.

  Hmmm.  Maybe a process cannot receive a signal when it is stopped?
I seem to recall that's the behavior.  You have to wake it up, then
the signals get delivered.  So when killall sends SIGHUP or SIGKILL,
the process doesn't get it until you wake it up, at which point it
gets delivered, and "alpine" promptly complies by exiting.

  So why does "kill -1" work?  Well, kill is a shell built-in.  Maybe
it is aware of job status in your shell, and "helps" you by sending
SIGCONT to wake it up.

  Of course, this doesn't explain why a different shell's invocation
does work.  But I think this might be an avenue of exploration worth
following for a bit.  So, what happens if, instead of using the
shell's built-in kill, you do:

	/bin/kill -1 $PID_OF_ALPINE

-- Ben