NOTE: Yes, I have a QWERTY keyboard. I also fully enabled SysRq with echo 1 > /proc/sys/kernel/sysrq while root earlier.

Tonight my laptop froze up while having Chromium and Minecraft open. After a while of waiting the system wouldn't respond again so I switched to tty1 (very slowly) and performed the safe reboot sequence (Alt-SysRq-REISUB). When I got to E, text began to fly on my monitor. After that my keyboard's CapsLock and ScrollLock indicators began to blink endlessly. The text on my monitor was about:

The top was the end of a traceback for a ext3 I/O function

Middle was full of errors concerning writing to somewhere on the disk, also errors about a bad superblock (!)

Last line was Kernel panic - not syncing: Attempted to kill init! (exitcode: 0x00000007)

When I rebooted I think fsck fixed the filesystem up (I guess Minecraft was in the middle of a save). My question is: why did Alt-SysRq-E kill init when it shouldn't?

2 Answers
2

That kernel panic is more likely was caused by that freeze which you experienced. When you issued the terminate all command with the magic combo, the kernel sent the SIGTERM signal to that misbehaving process which was causing your freeze, and because that was a misbehaving one, it decided to not die in the way a gentleman or a samurai should die when their death is needed, but instead it tried to handle that signal before dying and do something before its death. While it was handling that signal it caused some more problem to your already instable (freezing) system and that caused a kernel panic. (So the Alt+SysRq+E triggered that panic, but it wasn't the faulty for init's death. Or something similar to this happened, maybe with less drama.

If Minecraft does weird things when quitting on Windows, why wouldn't the same happen on Linux distros? Thank you
–
hunterturDec 30 '13 at 0:31

This is two hand wavy to be a good answer. Come on, "fight back"? A process is free to ignore SIGTERM, but when you get to the 'i' in the sequence, SIGKILL is unconditional.
–
psusiDec 30 '13 at 15:33

@psusi Did you read the question? When I got to E, text began to fly on my monitor. The e is before the i. And the meaning of my answer was that it wasn't the magic combo which killed init, but it was the misbehaving process which did something silly when received the SIGTERM signal. Because the system was in an instable state (freezeing) and that SIGTERM handling of that misbehaving process somehow caused a panic. (We do not know which process was that of course.) I'm sad that you didn't get what I tried to mean.
–
falconerDec 30 '13 at 21:23

I got your meaning. I'm saying that it is complete guesswork that is unlikely to have any relation to reality. I do like the flowery language but that sort of thing makes for a funny comment, not a good answer.
–
psusiDec 30 '13 at 23:55

@psusi LOL. The question was: why did Alt-SysRq-E kill init when it shouldn't? I answered it, and stated that the magic combo didn't caused the panic. Then I gave a POSSIBLE reason for the kernel panic. Even stated that it might not be the exact situation, but something similar have happened. Did you answer the question in your answer? NOT. (Your answer is a NAA, which should be a comment, I should flag it, but I won't, because that would be unsportsman) Is your answer a complete guesswork too? Yes it is! So what is your point here?
–
falconerDec 31 '13 at 0:17

You would need to get a photo or pay careful attention to the messages to be sure, but based on your description, my guess is that your disk was throwing IO errors ( not a good sign ), and this triggered a kernel OOPS in the filesystem driver when init tried to do some IO, and that is why init died.

You should use the disk utility to check the SMART status of the drive. Run the long self test ( this can take hours ) and make sure there are no bad sectors. If this happens again, try to get a photo of the errors.