[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: another 1.10 job control bug?



From: "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.)

Hm, I can't remember how BSD invalidates the tty descriptor of background
jobs. Certainly init should reset the process group of the tty when the
child that was spawned on it terminates. That in itself should prevent
any remaining jobs from writing, eh? But there must be more to it. Yah,
SunOS uses sessions *now*, but what was before them? (Dang, can't find
my 4.3 internals book right now...)