Why are not processes HUPped when they open /dev/console?

Why are not processes HUPped when they open /dev/console?

[Jiri Slaby]

Hello,

don't you remember by a chance the reason for this test in __tty_hangup:
  if (filp->f_op->write != tty_write)

The logic there is not to HUP processes that have this tty open via
/dev/console.

It is there like forever. But now, due to that, processes that do
vhangup of /dev/ttyXYZ wait infinitely if there is some other process
that has the ttyXYZ open through /dev/console. (Due to infinite wait in
tty_ldisc_hangup.)

This happens on some distros on shutdown path because they do vhangup on
all tty[0-8] ttyS[01] and similar.

thanks,
-- 
js
suse labs

Re: Why are not processes HUPped when they open /dev/console?

[Alan Cox]

On Wed, 25 Jan 2012 22:38:40 +0100
Jiri Slaby <jslaby@suse.cz> wrote:

> Hello,
> 
> don't you remember by a chance the reason for this test in __tty_hangup:
>   if (filp->f_op->write != tty_write)
> 
> The logic there is not to HUP processes that have this tty open via
> /dev/console.

Because if you hang up the console the machine crashes ?

At least that's what used to happen.

Alan

Re: Why are not processes HUPped when they open /dev/console?

[Jiri Slaby]

On 01/25/2012 10:45 PM, Alan Cox wrote:
> On Wed, 25 Jan 2012 22:38:40 +0100
> Jiri Slaby <jslaby@suse.cz> wrote:
> 
>> Hello,
>>
>> don't you remember by a chance the reason for this test in __tty_hangup:
>>   if (filp->f_op->write != tty_write)
>>
>> The logic there is not to HUP processes that have this tty open via
>> /dev/console.
> 
> Because if you hang up the console the machine crashes ?
>
> At least that's what used to happen.

It does not crash anymore. However the system (systemd more precisely)
is confused a bit (well, a huge). So I suppose the test has its meaning.

The whole exercise was about how to fix the userspace issue introduced
by the added infinite timeout.

I think the proper solution here is just not to call vhangup in
userspace for the device which is /dev/console. It never worked anyway.
Because the HUP signal was never sent and it always timed out.

thanks,
-- 
js
suse labs

Re: Why are not processes HUPped when they open /dev/console?

[Pavel Machek]

> On 01/25/2012 10:45 PM, Alan Cox wrote:
> > On Wed, 25 Jan 2012 22:38:40 +0100
> > Jiri Slaby <jslaby@suse.cz> wrote:
> > 
> >> Hello,
> >>
> >> don't you remember by a chance the reason for this test in __tty_hangup:
> >>   if (filp->f_op->write != tty_write)
> >>
> >> The logic there is not to HUP processes that have this tty open via
> >> /dev/console.
> > 
> > Because if you hang up the console the machine crashes ?
> >
> > At least that's what used to happen.
> 
> It does not crash anymore. However the system (systemd more precisely)
> is confused a bit (well, a huge). So I suppose the test has its meaning.
> 
> The whole exercise was about how to fix the userspace issue introduced
> by the added infinite timeout.

> I think the proper solution here is just not to call vhangup in
> userspace for the device which is /dev/console. It never worked anyway.
> Because the HUP signal was never sent and it always timed out.

Perhaps the "infinite timeout" should be reverted, then? It sounds
like a regression...



-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Why are not processes HUPped when they open /dev/console?

[Jiri Slaby]

On 02/06/2012 08:24 PM, Pavel Machek wrote:
>> On 01/25/2012 10:45 PM, Alan Cox wrote:
>>> On Wed, 25 Jan 2012 22:38:40 +0100
>>> Jiri Slaby <jslaby@suse.cz> wrote:
>>>
>>>> Hello,
>>>>
>>>> don't you remember by a chance the reason for this test in __tty_hangup:
>>>>   if (filp->f_op->write != tty_write)
>>>>
>>>> The logic there is not to HUP processes that have this tty open via
>>>> /dev/console.
>>>
>>> Because if you hang up the console the machine crashes ?
>>>
>>> At least that's what used to happen.
>>
>> It does not crash anymore. However the system (systemd more precisely)
>> is confused a bit (well, a huge). So I suppose the test has its meaning.
>>
>> The whole exercise was about how to fix the userspace issue introduced
>> by the added infinite timeout.
> 
>> I think the proper solution here is just not to call vhangup in
>> userspace for the device which is /dev/console. It never worked anyway.
>> Because the HUP signal was never sent and it always timed out.
> 
> Perhaps the "infinite timeout" should be reverted, then? It sounds
> like a regression...

It *is* a regression in the shutdown path, yes. The point is that
previously it silently proceeded and freed the structures. This was
causing crashes. And it also misbehaved as it was supposed to wait for
all to vanish.

OTOH now it (possibly infinitely) waits for all of them. With the code
as it stands now, I cannot think of any other easy way to fix that. Do
what you have to. Revert, if you think occasional (nearly exceptional)
crashes are better than the regression...

thanks,
-- 
js
suse labs