Red Hat Bugzilla – Bug 491474
SAK is not working on tty1, where graphical login is
Last modified: 2014-06-18 04:46:35 EDT
Description of problem:
SAK (Alt-SysRq-K) is no longer working in X. When this combination is pressed to restart X server, system just hangs, without even syncing to disk, display is corrupted, magic key is not working.
If you need to login into server or workstation from graphical console, you can switch to text console tty2..tty6, use SAK to clean console from any malicious software, which is left by previous user, then login into system, verify owner of GDM and X processes or just kill them, then switch back to tty1 and login into system using graphical console.
Steps to Reproduce:
1. Boot Fedora in graphic mode.
2. Press Alt-SysRq-K
System is hangs without syncing to disk due to kernel panic: "Kernel panic - not syncing: Attempted to kill init!"
X server and GDM are restarted.
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
This still happens with F12, please see https://bugzilla.redhat.com/show_bug.cgi?id=528260
Nice example of racism in Open Source.
Yes, this bug is still exists in Fedora 11/12.
Strange. I didn't get any mails about being assigned this bug, never seen it before.
First question: Are you really running initng? The bug is classified as initng, but I see nothing in the description that indicates that initng is really used. If you ARE using initng, I can recommend switching to upstart as initng isn't maintained all that much anymore.
Currently, I use upstart-0.3.11-1.fc11.i586 on my notebook.
Problem is not in initialization subsystem itself: init, initng or upstart. Problem in configuration of init subsystem and/or kernel behaviour.
When SysRQ-K combination (SAK) is pressed on tty1, *kernel* kills *all* processes on this tty, including all daemons, including init process, and then hangs because init process is killed. It is *bad idea* to use SAK on tty1.
In public environment (e.g. computer class in school) SAK is highly recommended, otherwise smart child will leave slightly modified version of GDM left running and will fool next user.
Unfortunately, X servers is moved from tty7 to tty1, so there is no other protection from smart children except reboot.
To fix that problem, upstart must be configured to use any other tty except tty1 for X server. Moreover, tty1 should not be used to login into system at all and SAK key should be disabled for tty1 in kernel.
Ok. I'll change asignee then to the one responsible for upstart.
If SAK is killing *init* something else weird is going on, it has nothing to do with where the X server is.
> If SAK is killing *init* something else weird is going on, it has nothing to do
with where the X server is.
SAK kills *all* processes on tty1, including all daemons, including init.
Quote from kernel/Documentation/SAK.txt:
On the PC keyboard, SAK kills all applications which have /dev/console opened. Unfortunately this includes a number of things which you don't actually want killed.
This is because these applications are incorrectly holding /dev/console open. Be sure to complain to your Linux distributor about this!
[vlisivka@apollo 1]$ sudo fuser -v /dev/console
USER PID ACCESS COMMAND
/dev/console: root 1 F.... init
root 1258 F.... rsyslogd
[vlisivka@apollo 1]$ sudo fuser -v /dev/tty1
USER PID ACCESS COMMAND
/dev/tty1: root 1878 F.... Xorg
SAK on tty1 will kill Xorg and /sbin/init with rsyslogd.
Upstart definitely holds a /dev/console fd. Might be useful to just preclude pid 1 from SAKing.
If notting agrees I'll move this to kernel and write the patch.
Is there a real reason to hold a /dev/console fd?
Especially now that rhgb is dead and we don't need to do redirection in that way.
I'll move this into launchpad then and get Scott's input.
*** Bug 528260 has been marked as a duplicate of this bug. ***
This is fixed in 0.6.5. Can the reporter or anyone else verify its absence on F13?
works as expected on my F13 with upstart-0.6.5-3.fc13.i686