2

Why can't root send a fatal signal to PID 1/init process (sudo kill -9 1)?

As stated here.

Community
  • 1
Bleeding Fingers
  • 991
  • Because it is a dangerous way to reboot the system. – doneal24 Oct 16 '13 at 18:20
  • couldn't the kernel spawn another, as soon as it detects the absence of one? – Bleeding Fingers Oct 16 '13 at 18:25
  • @hus787 It could, but the only process the kernel spawns is init (or nowadays, an init replacement). init takes care of spawning processes. There isn't really a reason to kill init. – kurtm Oct 16 '13 at 19:08
  • 1
    @kurtm there is one: suppose you log into your remote system and realize you have an attacker there. Before you manage to do anything else, he realizes you know of his presence and issues rm -Rf /. In that case kernel panic is the best way to save as much data as possible - kill -9 1 is (or would be) the only fast way to trigger one remotely. I actually believe it was possible on Linux years ago. (/me is not in the mood of looking that up now.) – peterph Oct 16 '13 at 19:12
  • Interesting reading about implementation on Linux: http://flossstuff.wordpress.com/2013/08/16/why-you-cant-kill-init/ – peterph Oct 16 '13 at 19:16
  • @peterph went through that link before I posted here. – Bleeding Fingers Oct 16 '13 at 19:18
  • @peterph For that case a halt that didn't do all the graceful shutdown stuff (which used to be common but is rare now) would be a better bet. The only reason that Linux kernel panicked in the referred article is essentially because the author didn't take out all of init's special-case protections. And if the attacker has root, he could easily block your kill. It would be more interesting to see what started going wrong if you could kill init without all the special casing. – kurtm Oct 16 '13 at 19:25

0 Answers0