0

There is a mysterious tty that only reacts to sysrq, not to any other keyboard input.

It started after I engaged SysRQ+F and SysRq+i.

Every 30 seconds or so, Linux switches away from the current tty to that strange, uncontrollable tty that contains the most recent dmesg's.

Each line starts with the uptime such as [2312154.4828572]

Ctrl+Alt+F# does not get me out of there.

What is this mysterious tty?

  • 2
    If ctrl+alt+f# does not get you out of there, then how do you know it happens every 30 seconds? aren't you stuck in it already? Or is there another way to switch out of it? – sourcejedi Dec 11 '18 at 22:34
  • @SourceJedi I already restarted my computer. The next time this phenomenon happens, I will examine it further. It gets unstuck after around 30 seconds and leaves me on a black tty7 (not even blink cursor). However, I can then switch to my desired tty. – neverMind9 Dec 11 '18 at 23:00
  • 1
    Did you try SysRQ+R? That might let ctrl+alt+f# work, in case the tty is in raw mode. – sourcejedi Dec 11 '18 at 23:12
  • 1
    Where does your kernel come from? What is your Linux distribution (and version) ? – sourcejedi Dec 11 '18 at 23:17
  • Sysrq+R did not work. Mine was Linux Mint Xfce 18.2 (live session). Now using Linux Mint KDE 18.3 (live session). Each in 64bit. – neverMind9 Dec 12 '18 at 1:26
3

Your mysterious “kernel buffer view” seems to be similar to what the system looks like when it’s only running the kernel and an init process. (But that doesn’t explain the apparent console switching.)

SysRqI kills all processes apart from init. Your desktop session is gone, all the system dæmons are gone… init should restart some gettys, so you should be able to log in, but perhaps it isn’t doing this on your system. So you end up on one of the virtual consoles; whichever one you switch to will look similar to any other, but the kernel messages only go to the current virtual console, which results in the impression you describe.

In this situation, there’s nothing to recover apart from unflushed data, so SysRqSUB is the way to go.

  • But it switches from the tty's I can interact with to the “kernel buffer view” and back. Unlike usually, where it would print directly into the currently active tty, “kernel buffer view” acts as if it were a seperate tty but it blocks the keyboard. When it switches back to the interactable state, the contents in the usual tty's are not gone. – neverMind9 Dec 12 '18 at 23:53
  • Side note: Thank you for reminding me about the <kbd>KBD tag</kbd>. – neverMind9 Dec 12 '18 at 23:55
  • Please do not delete it. Your answer is still informative. – neverMind9 Dec 13 '18 at 9:25
  • I unaccepted it for now to signalize to other users that this question is open. Do not take it personally. – neverMind9 Dec 13 '18 at 9:35
  • 1
    No worries, I’m also curious to find out what’s going on here ;-). – Stephen Kitt Dec 13 '18 at 9:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.