Process control and such

[Bill Sconce]

On Wed, 25 Jan 2006 16:45:34 -0500
Bill KE1G <f at ke1g.mv.com> wrote:

Ben> Someone at last night's meeting (I already forget who it was) was


'Twas me.  I knew I asked *someone* about it.  :)


Ben> reporting an issue where they start some program from one window,
Ben> program opens a new window, then they close the first window, and the
Ben> program (new window) dies too.  I've forgotten the details, too. 
Ben> (Geez, only 28 and I'm already going senile.)


Right.  It's bothered me more than once.  One way to state the problem --
let's say you've discovered that you repeatedly have to do something.
You want to be able to launch it quickly and conveniently.

(My real use case was editing a frequently-used file, but to keep the
example simple I'll use xclock.)

The first thing you do might be to invent a shortcut which can be used
in a terminal window:

    $ toc() { /usr/bin/X11/xclock & }
    
Now you can just type a command "toc".  And your command runs, and you
can go on to do other things in the terminal window.

BUT.

What happens to the running command later on ... "depends".  

IF you type "exit" in your terminal window the command keeps on running.
(Which is presumably what you want.)  BUT if you close the terminal
window with the window-manager "X" button...  both the terminal window
and the child command go away.  The same kind of thing gets in your way
if you try to hook certain commands associated with terminal windows
to shortcuts in a window manager.  Confusing, and a little bit subtle. 
I've bumped into it several times in different contexts but I've never
been able to track it down.  (This has been one of those Unix-y
head-scratching problems, "it must be documented *somewhere*, but 
*which* F M do I R?")
 
Bill Freeman KE1G wrote:
KE1G> Well, I wasn't there for the discussion, but, yes, process
KE1G> groups are probably involved.
KE1G> 
KE1G> 	Usually you don't have to think about this kind of stuff
KE1G> because you start such a program "in the background" by giving the
KE1G> shell an ampersand at the end of the list.  The shell then puts the
KE1G> list (I'm pretty sure that it works for a whole list, rather than only
KE1G> for a pipe or a single process) in its own process group.  Then, when
KE1G> the closing window sends the shell's process group a HUP, the
KE1G> background process don't receive it, and continue to run.

Bingo!

KE1G> If, instead of just backgrounding commands from the shell,
KE1G> you're writing some code that backgrounds itself or creates children
KE1G> that are intended to be persistant, then you do need to worry about
KE1G> process groups yourself.  Check out the setpgrp(2) man page.

Ah HA.  The good ol' setpgrp(2) F M.  Of course!   :)

Thanks, Bill!

(Seriously, it explains what's been going on, and for a couple of
years this has been an opaque puzzle to me.  Now it makes sense.  And
I'll probably even be able to solve the problem, as soon as I find
out how  setpgrp() can be controlled from Python.  I see that there
are Google hits for that.  (It doesn't seem to be in )


-Bill (Sconce) N1BFK


______________________________________________________________________
Here's the man page's explanation, in case anyone else is interested.
(There may not be a setpgrp(2) man page on all Linux systems -- there
is none on mine.)  ">>"s mark where the light dawned.

    setpgid sets the process group ID of the process specified by pid 
    to pgid. If pid is zero, the process ID of the current process is
    used. If pgid is zero, the process ID of the process specified by
    pid is used. If setpgid is used to move a process from one process
    group to another (as is done by some shells when creating pipelines),
    both process groups must be part of the same session. In this case,
    the pgid specifies an existing process group to be joined and the
    session ID of that group must match the session ID of the joining
    process.

    Similarly, getpgrp() is equivalent to getpgid(0). Each process
    group is a member of a session and each process is a member of 
    the session of which its process group is a member.

>>  Process groups are used for distribution of signals,   <<
    and by
    terminals to arbitrate requests for their input: Processes that
    have the same process group as the terminal are foreground and 
    may read, while others will block with a signal if they attempt
    to read. These calls are thus used by programs such as csh(1) 
    to create process groups in implementing job control. The 
    TIOCGPGRP and TIOCSPGRP calls described in termios(3) are used
    to get/set the process group of the control terminal.

>>  If a session has a controlling terminal, CLOCAL is not set and
>>  a hangup occurs, then the session leader is sent a SIGHUP. If
>>  the session leader exits, the SIGHUP signal will be sent to
>>  each process in the foreground process group of the controlling
>>  terminal.

    If the exit of the process causes a process group to become 
    orphaned, and if any member of the newly-orphaned process group
    is stopped, then a SIGHUP signal followed by a SIGCONT signal 
    will be sent to each process in the newly-orphaned process group.