another 1.10 job control bug?

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

>From: miff@asharak.apana.org.au (michael smith)
>In <199403042253.RAA07033@terminator.rs.itd.umich.edu> you wrote :
>>My only problem with it as a permanent solution is that a process
>>hanging around in the foregroung process group could prevent the
>>controlling tty from ever being released, causing the
>>you-only-get-one-login-per-device problem again.  One way this could
>>happen is if an asynchronous process is spawned from a
>>non-job-control-aware shell (e.g. one that knows nothing about process
>>groups).  I guess this isn't a big enough problem to be concerned
>>about at the moment, unless there are other ways this could happen.
>
>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.)

Cheers,
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