On Friday 18 March 2005 12:00, shimi wrote:
If you kill a process, all the processes that were spawned by it are being killed as well [or supposed to be].
What you just described may exist in some other operating system, but is definitely not Unix/Linux/Posix behavior.
Funny, I could *swear* it happend to me in the past (like 7 years ago). (happend to me when I killed bash on a different connection, and my session died, although I was *in* a program). But I did work on many different systems back then, so, who knows :) Thanks for the heads up :)
There are several common reasons for whole groups of processes to die together:
1. Killing a process group: Typically a shell puts every "job" in a separate process group. Things like the shell command ``kill %3`` (but not ``kill 5274``) and pressing Ctrl-C at the terminal send a signal to the whole process group. This makes a lot of sense: e.g. when you kill a running make you normally want to kill any gcc it has spawned.
2. SIGHUP: usually terminates all processes attached to the terminal.
* If the terminal is disconnected, the controlling process group of the
terminal (normally consisting of the login shell process) get SIGHUP.
A normal shell then exits, first re-sending SIGHUP to all subprocesses;
a subprocess can be excluded from this re-sending by ``disown <jobspec>``
in bash and ``nohup <command>`` in tcsh. Shells by default do *not* send SIGHUP to children when exiting normally
(e.g. by Ctrl-D); this can be forced by ``shopt -s hupopexit`` in bash
and ``hup <command>`` in tsch. * When a session leader terminates for whatever reason, the forground
process group gets a SIGHUP. This is probably what happened in the case
you describe. * Any process surviving after the controlling process has died are called
"orphaned" and can't access the terminal. Attempting to do so doesn't
stop the process but depends on the system (SIGHUP or SIGKILL are
typical).3. SIGPIPE: a process trying to write to a pipe or FIFO that doesn't have a reading process gets a SIGPIPE (which by default kills it). This is what prevents wasted effort in commands like ``find / grep foo | head`` - when head exits, grep gets a SIGPIPE and dies, which couses find to get a SIGPIPE.
If you want deeper detail, `info libc` has *very* good explanations about signal handling and job control.
How can ssh know that no children of the shell are still doing something useful to the user? They could be using the terminal or ssh's X forwarding. I'm not sure from the above description how can a subprocess still use the terminal after the shell exits - perhaps a foreground job that catches/ignores SIGHUP. I do think that I saw programs printing something after the shell has exited.Still, why isn't that a good idea? You're leaving the program that sshd spawned (and it knows what it spawned, right?), which means you obviously want to stop ssh doing "his thing" for which you negotiated in the first place... I cannot see a reason to leave a stale session, which you really can't do anything with (like running 'fg' to take the process back to your control and communicate with it) ?
Anyway, there is a point to your complaint: if the shell exits and ssh still runs, very probably only port forwarding is still used and it would be nice if ssh would background itself (*not* just exit - if port forwarding is used, you *want* ssh to keep running). The ~& escape seems to do something like this:
~& background ssh at logout when waiting for forwarded connection / X11
sessions to terminate.
(from man ssh)It appears that you have to type it (after Enter) when ssh remains "stuck". You might want to ask on the openssh mailing list to get more details - and a chance that your proposal of doing it automatically gets implemented.
-- Beni Cherniavsky <[EMAIL PROTECTED]>, who can only read email on weekends.
================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
