Re: another 1.10 job control bug?

[miff@asharak.apana.org.au (michael smith)]

In <199403060937.EAA09091@terminator.rs.itd.umich.edu> you wrote :

>>Hmm, and it shouldn't be a problem anyway - when DCD drops/the TCP link is
>>closed/or any other 'true' logout action occurs, init should terminate 
>>all processes that claim to have that line as a controlling tty.
>
>I don't think init has enough information to do this.  Under MiNT this
>should be under the kernel's control.  And even if the kernel did
>handle this, it would only apply if the CLOCAL bit were not set in the
>tty flags, and would only have the desired effect if the process
>doesn't ignore SIGHUP (for instance, users should be able to start a
>daemon interactively from the modem1 tty using a non-job-control aware
>shell, then log out, and expect the port not to get locked up.)

Firstly, users shouldn't be using non-job-control-aware shells, so we can
toss that one out 8)

Yes, correct, if the process is ignoring SIGHUP then it shouldn't go
away, but it _should_ lose the tty.

What I mean is this : if I try (output omitted)

% frob datafile
...
^Z
{% bg}
% logout

I would expect to get a message indicating that there are stopped 
{backgrounded} jobs. (probably from the shell being polite)

If I were to do :

% frob datafile &
% logout

Then I would expect to be able to logout and know that frob is running
happily without a tty, and not laying claim to mine.

>Cheers,
>entropy

Bop me one if I'm barking up the wrong tree here, but once the user
indicates that they're leaving, the tty should be free. If there
are processes that think that it's still theirs, this is a bug.



--
--
mike smith : silicon grease monkey  | If you think it can't be done, |
miff@asharak.apana.org.au           | it means you don't have enough |
miff@apanix.apana.org.au            | money in your budget.          |