On Wed, 25 Jan 2006 16:45:34 -0500
Bill KE1G <[EMAIL PROTECTED]> 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.
_______________________________________________
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
