Re: Scroll Lock on VT prevents reboot/shutdown

[Felix Miata]

David Wright composed on 2016-09-30 18:58 (UTC+0300):


On Fri 30 Sep 2016 at 18:06:18 (+0300), Reco wrote:



Presumably systemd has its merits, but VT handling is not one of them.
I agree that there're many cornercases in sysvinit's VT handling, but
inability to shut down and reboot is always a touchy subject to me.



But I'm not intending to start a flamewar here (although it's a Friday
night ;), this 'unable to reboot' thing is clearly a minor bug ether in
systemd or jessie's kernel.



Agreed. I get fed up looking at a screen that says, say,
"A stop job is running for LSB: RPC portmapper replacement (22min 51s / no 
limit)"
or worse, the ones where there's a 90sec timeout which, as soon as it
is reached, changes to 180sec, and so on, 90sec by 90sec ad infinitum.
Linux used to be able to close down irrespective of stalled services.
Now you have to risk corrupting filesystems by forcibly powering off.


I asked about systemd's start job/stop job reboot delays on the systemd-dev 
list over 21 months ago, but never have run across anything being done about 
it. Most recently I've seen it because nfs server does not start, so can't be 
stopped at shutdown.


https://lists.freedesktop.org/archives/systemd-devel/2015-January/027214.html
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Scroll Lock on VT prevents reboot/shutdown

[David Wright]

On Fri 30 Sep 2016 at 18:06:18 (+0300), Reco wrote:

> Presumably systemd has its merits, but VT handling is not one of them.
> I agree that there're many cornercases in sysvinit's VT handling, but
> inability to shut down and reboot is always a touchy subject to me.
> 
> But I'm not intending to start a flamewar here (although it's a Friday
> night ;), this 'unable to reboot' thing is clearly a minor bug ether in
> systemd or jessie's kernel.

Agreed. I get fed up looking at a screen that says, say,
"A stop job is running for LSB: RPC portmapper replacement (22min 51s / no 
limit)"
or worse, the ones where there's a 90sec timeout which, as soon as it
is reached, changes to 180sec, and so on, 90sec by 90sec ad infinitum.
Linux used to be able to close down irrespective of stalled services.
Now you have to risk corrupting filesystems by forcibly powering off.

Cheers,
David.

Re: Scroll Lock on VT prevents reboot/shutdown

[Reco]

Hi.

On Fri, 30 Sep 2016 10:09:25 -0300
Henrique de Moraes Holschuh  wrote:

> On Fri, 30 Sep 2016, Reco wrote:
> > On Thu, Sep 29, 2016 at 10:03:31PM +, Matt Sickler wrote:
> > > I'm not sure which package this bug should be filed against, partially 
> > > because I'm not entirely sure of the root cause.  I'm able to replicate 
> > > it on our systems every time, though I have not tried on a fresh install 
> > > of Debian - our images aren't really that much different anyway.   We 
> > > don't have a GUI installed, just text mode or whatever you want to call 
> > > it.  I've spent hours googling and I have not found anyone else affected 
> > > by this, nor did I find anything in BTS.
> > 
> > > Could someone confirm that this happens on more than just my systems 
> > > and/or let me know what package I should file the bug against?
> > 
> > Please run "dpkg -S /sbin/shutdown", and file a bug against a package
> > found. I suspect that this issue must be linked somehow to systemd's
> > console handling, because I cannot reproduce the behavior you describe
> > (but I don't use systemd).
> 
> Hmm, careful there. sysv-rc console handling isn't much better, I don't
> know when we regressed it or why anymore, it was on lenny or even
> earlier, but...

I can get a Unicode VT console without any hassle with sysvinit.
I can get my hosts rebooted without fiddling with stty with sysvinit.
I cannot do both (as of jessie) with systemd.

Presumably systemd has its merits, but VT handling is not one of them.
I agree that there're many cornercases in sysvinit's VT handling, but
inability to shut down and reboot is always a touchy subject to me.


But I'm not intending to start a flamewar here (although it's a Friday
night ;), this 'unable to reboot' thing is clearly a minor bug ether in
systemd or jessie's kernel.



> If you ever need to log in the console before getty ran
> (i.e. in single-user mode, etc), *always* run "stty sane" as the first
> thing.
> Otherwise, you might find yourself on a shell that doesn't have many of
> the interrupt signals working from the vty.

I don't know as I never tried that. Either getty is working for me or
I'm booting with init=/bin/sh. But thank you for the advise.

Reco

Re: Scroll Lock on VT prevents reboot/shutdown

[Henrique de Moraes Holschuh]

On Fri, 30 Sep 2016, Reco wrote:
> On Thu, Sep 29, 2016 at 10:03:31PM +, Matt Sickler wrote:
> > I'm not sure which package this bug should be filed against, partially 
> > because I'm not entirely sure of the root cause.  I'm able to replicate it 
> > on our systems every time, though I have not tried on a fresh install of 
> > Debian - our images aren't really that much different anyway.   We don't 
> > have a GUI installed, just text mode or whatever you want to call it.  I've 
> > spent hours googling and I have not found anyone else affected by this, nor 
> > did I find anything in BTS.
> 
> > Could someone confirm that this happens on more than just my systems and/or 
> > let me know what package I should file the bug against?
> 
> Please run "dpkg -S /sbin/shutdown", and file a bug against a package
> found. I suspect that this issue must be linked somehow to systemd's
> console handling, because I cannot reproduce the behavior you describe
> (but I don't use systemd).

Hmm, careful there. sysv-rc console handling isn't much better, I don't
know when we regressed it or why anymore, it was on lenny or even
earlier, but...  If you ever need to log in the console before getty ran
(i.e. in single-user mode, etc), *always* run "stty sane" as the first
thing.

Otherwise, you might find yourself on a shell that doesn't have many of
the interrupt signals working from the vty.

One thing to try: if shutdown hangs because a console is paused, please
wait.  It is supposed to eventually (i.e. after several minutes) time
out and go into a sigkill spree that should unwedge even a process stuck
in a tty read or write (the ttys are NOT supposed to get a process into
"D" state AFAIK).  If it doesn't, we have a kernel bug on top of
everything else.

-- 
  Henrique Holschuh

Re: Scroll Lock on VT prevents reboot/shutdown

[Reco]

Hi.

On Thu, Sep 29, 2016 at 10:03:31PM +, Matt Sickler wrote:
> I'm not sure which package this bug should be filed against, partially 
> because I'm not entirely sure of the root cause.  I'm able to replicate it on 
> our systems every time, though I have not tried on a fresh install of Debian 
> - our images aren't really that much different anyway.   We don't have a GUI 
> installed, just text mode or whatever you want to call it.  I've spent hours 
> googling and I have not found anyone else affected by this, nor did I find 
> anything in BTS.

> Could someone confirm that this happens on more than just my systems and/or 
> let me know what package I should file the bug against?

Please run "dpkg -S /sbin/shutdown", and file a bug against a package
found. I suspect that this issue must be linked somehow to systemd's
console handling, because I cannot reproduce the behavior you describe
(but I don't use systemd).

Reco

Re: Scroll Lock on VT prevents reboot/shutdown

[davidson]

Some caveats, below, qualifying the claims in my previous reply to OP.

On Fri, 30 Sep 2016, david...@freevolt.org wrote:


On Thu, 29 Sep 2016, Matt Sickler wrote:
[intro cut away]


Here's how to replicate the bug:
1) Log in as a normal user on a VT/
2) Start nano.  If nano is not available, I think any
 application that interacts with the user would work, but
 I've only tried using nano.
3) Hit Scroll Lock - At this point, anything you type will get
 buffered somewhere and won't show up until you turn off
 Scroll Lock.  Leave it on for the moment.
4) Switch to a different VT using Alt+F2 or do these next
 steps from an SSH session
5) Run "sudo reboot" or "sudo shutdown"
6) The system will start rebooting (some services will stop)
 but it will "hang" in the reboot until you go back to the
 first VT and turn off Scroll Lock.


[remote access workaround stuff cut away]


Could someone confirm that this happens on more than just my systems
and/or let me know what package I should file the bug against?


RE confirmation: I tested your steps 1--6 on a recent install of
jessie, and it behaved exactly as you describe.


Having repeated the experiment many times (~50) on jessie now, I must
add that it is a frustratingly fiddly bug. I cannot reproduce it
reliably, although it does indeed occur occassionally.

Also, just in case it matters, I replace step 5 with...

 # reboot

...since sudo is not installed on the jessie system I am using to
investigate.


For whatever it is worth, I also tested them on a not-so-fresh wheezy,
which did not display this behavior.


In light of the fiddly-ness noted above, I cannot be sure that wheezy
is unaffected (since thus far I have only tried to replicate the bug
on wheezy a couple of times).

Re: Scroll Lock on VT prevents reboot/shutdown

[davidson]

On Thu, 29 Sep 2016, Matt Sickler wrote:
[intro cut away]


Here's how to replicate the bug:
1) Log in as a normal user on a VT/
2) Start nano.  If nano is not available, I think any
 application that interacts with the user would work, but
 I've only tried using nano.
3) Hit Scroll Lock - At this point, anything you type will get
 buffered somewhere and won't show up until you turn off
 Scroll Lock.  Leave it on for the moment.
4) Switch to a different VT using Alt+F2 or do these next
 steps from an SSH session
5) Run "sudo reboot" or "sudo shutdown"
6) The system will start rebooting (some services will stop)
 but it will "hang" in the reboot until you go back to the
 first VT and turn off Scroll Lock.


[remote access workaround stuff cut away]


Could someone confirm that this happens on more than just my systems
and/or let me know what package I should file the bug against?


RE confirmation: I tested your steps 1--6 on a recent install of
jessie, and it behaved exactly as you describe.

For whatever it is worth, I also tested them on a not-so-fresh wheezy,
which did not display this behavior.

RE what package is responsible: No idea.

Scroll Lock on VT prevents reboot/shutdown

[Matt Sickler]

I'm not sure which package this bug should be filed against, partially because 
I'm not entirely sure of the root cause.  I'm able to replicate it on our 
systems every time, though I have not tried on a fresh install of Debian - our 
images aren't really that much different anyway.   We don't have a GUI 
installed, just text mode or whatever you want to call it.  I've spent hours 
googling and I have not found anyone else affected by this, nor did I find 
anything in BTS.

Here's how to replicate the bug:
1) Log in as a normal user on a VT/
2) Start nano.  If nano is not available, I think any application that 
interacts with the user would work, but I've only tried using nano.
3) Hit Scroll Lock - At this point, anything you type will get buffered 
somewhere and won't show up until you turn off Scroll Lock.  Leave it on for 
the moment.
4) Switch to a different VT using Alt+F2  or do these next steps from 
an SSH session
5) Run "sudo reboot" or "sudo shutdown"
6) The system will start rebooting (some services will stop) but it 
will "hang" in the reboot until you go back to the first VT and turn off Scroll 
Lock.

I have not found a way to prevent the bug from happening.  If you have physical 
console access, the obvious solution is to switch to the affect VT and disable 
scroll lock.  If you only have remote access, then running this will unblock 
the console:
sudo stty -F /dev/console ixon ; sudo stty -F /dev/console -ixon
I came across that workaround after digging through the TTY code and seeing 
this which made me think to try toggling ixon.  Note that this only works if 
you already have an SSH session before initiating the shutdown/reboot - nologin 
prevents new sessions from starting otherwise.

Could someone confirm that this happens on more than just my systems and/or let 
me know what package I should file the bug against?