Subject: Re: job-control shell trouble
To: None <tech-userlevel@netbsd.org>
From: Christos Zoulas <christos@zoulas.com>
List: tech-userlevel
Date: 12/26/2004 23:57:13
In article <200412262032.PAA13732@Sparkle.Rodents.Montreal.QC.CA>,
der Mouse <mouse@Rodents.Montreal.QC.CA> wrote:
>>> It is admittedly _unlikely_ that all the old processes will die and
>>> some other process in the same session will recreate the process
>>> group, without my having noticed that all the old processes have
>>> died and thus realizing that the process group is gone. But
>>> "unlikely" really isn't good enough.
>> In this particular case, it is good enough. From the manual page for
>> setpgid:
>
>> If the invoker is not the super-user, then the affected process
>> must have the same effective user-id as the invoker or be a
>> descendant of the invoking process.
>
>Yes, the *affected* process. But the affected process is always an
>inferior of my shell.
>
>My example looks like this:
>
> - session leader
> - some other process, pid A, pgrp A
> - my new shell, pid B, pgrp B
>
>Now, my shell, B, forks process C. As the first process of a new job,
>its PID gets used for the pgrp for the job, so it gets pgrp C.
>
>This process runs for a while, then dies. My shell reaps the zombie,
>forks again, and gets PID D. Now, I have a problem.
>
>If process C forked a child which is still around, pgrp C is still
>around, and C is the right pgrp to put D into. But if C's pgrp died
>with it, then it's possible that, after I reaped C's zombie, A forked,
>got PID C, and has recreated pgrp C - and C is then the wrong pgrp for
>me to use for D. But in either case, an attempt to put D into pgrp C
>will succeed. I can't see any way for B to tell which case obtains.
The "after I reaped" is really "after B reaped", so "B" knows that "C"
is gone. It can then choose to the process group of "D" to "D". The
situation is really more interesting when the shell forks a pipeline,
but this is not the situation here.
christos