another 1.10 job control bug?

["Nicholas S Castellano" <entropy@terminator.rs.itd.umich.edu>]

>What you wrote:
>> 
>> > Just FYI...  Things don't seem to work they way we'd like 'em, even on
>> > "real Unix".
>> 
>> On "real Unix" background jobs do not vanish on logout, but you are on
>> Sys V. :-)   Seriously, there is a difference in behaviour between
>> BSD and SysV based systems.  On BSD derivatives nohup does exist, but
>> it is mostly supreflous besides of portability issues.  Come to think
>> of it, I do not know how this is on SGI, which is a strange cross
>> between BSD and SysV.
>
>Ah, but does POSIX say anything at all about this, uh, "feature" of SysV?
>I suppose if it does, that'll be the deciding factor...

nohup is not superfluous.  Processes get SIGHUP signals on both SysV
and BSD when the controlling tty is logged out (sometimes controllable
by the CLOCAL and HUPCL modes in effect.)

I was only using daemons as an example of the problem I was
describing; the problem is not unique to them.  Normally a daemon will
assign a signal handler to SIGHUP, to mean "please re-read your
configuration now".  So the SIGHUP generated by logging out is usually
harmless, and you usually do NOT want to nohup a daemon (otherwise you
won't be able to reconfigure it).  All this is entirely irrelevant.

What we're discussing is what happens to a process that thinks it
still has a controlling tty once that tty has been logged out.  (or,
more precisely, how to decide what "logging out a session" means under
MiNT.  Once we decide what it means to log out, it should be trivial
to do the right thing for those processes.)

Under SysV, processes are allowed to continue writing to the terminal
if they have open file descriptors on it, but they stop receiving job
control signals from the terminal.  Under BSD 4.2, the vhangup()
routine in init revokes access to all open file descriptors on the
controlling tty and further reads or writes return "invalid handle".
Both behaviors are allowed by POSIX (although there is no vhangup()
and the behavior may be slightly different, the general scheme
permitted by POSIX is the same.)

My old routine definitely does have a bug...Juergen's patch (WITH THE
FIX I SENT OUT A DAY OR SO AGO) works a bit better.  For now, it would
be best to use that scheme, and perhaps modify getty slightly to take
any strange cases into account:  the first thing it should do is
"steal" the terminal from any existing processes that think they own
it, by changing the process group of the terminal.

Ah, confusion...
entropy

--
entropy -- it's not just a good idea, it's the second law.
Personal mail:      entropy@gnu.ai.mit.edu
MiNT library mail:  entropy@terminator.rs.itd.umich.edu
"what do you have against octal?" -jrb