What if boot like this:

Pass INIT=/bin/sh(or /bin/bash) parameter to kernel, through GRUB command line or similar ways, then boot;
Once shell is loaded, exit immediately. Then the computer has no response to any key pressed.

I am quite curious about the STATUS of the system at this moment. As I have learned that init is the first process which would be executed once kernel is loaded and other processes are all forked from it, it seems that when execute /bin/sh as described above instead of init with normal boot procedure, then system has no processes any more and nothing to do.

Is it idle like running

while (1) {

or what else?

Thanks all of you for your advices. Maybe more information is helpful, which I used to think as unnecessary.

I worked on a CentOS 7.2 server recently, and one XFS disk partition is not normal that it cost endless time doing check and recover when system booted. I planed to edit /etc/fstab to turn off auto mounting of this partition. As normal boot procedure was stuck, I used init=/bin/bash to make system boot into bash. After edit fstab, I executed shell exit carelessly, then no response on screen to any key pressed including Ctrl-Alt-Del, and no information prompted kernel panic(I could not tell whether CPU was hard working because that room was very noisy). I regarded it as idle as just nothing to do. This phenomenon made me think about the question I wrote down at beginning.

And I made some tests tonight, on my own notebook computer with Debian 8. Kernal panic obviously.

  • Did you try to do that or is this just speculation? (You did start with "what if...") – ilkkachu Apr 24 '17 at 19:14
  • @ilkkachu Thank you to remind me. In fact I have met a strange situation days ago, which made me think of this question with some speculation. I will make some complement. – rustyhu Apr 25 '17 at 16:15

I'm surprised. My understanding was that terminating PID 1 causes a kernel panic. I can tell you what happened in that case.

Panic behaviour is configurable. With the default options, you will reach a loop that looks exactly as you say.

The delay function used is documented as being a "busy-wait". It is not expected to enter the power-saving CPU sleep states used when the OS idles normally.

If you look at the backtrace printed by the panic, I think you see this all happens within sys_exit(). I think technically PID 1 doesn't get destroyed, it just never returns from making that system call. Any other CPUs are stopped first.

(There is something called a "boot idle thread". I don't see it involved in this process. AFAICT you can never see this thread. And if you wanted to understand it as an idle thread, you'd also have to ask what provides the idle thread for the other cpus once they are brought online).

  • Yep, you'd get Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000.... – ilkkachu Apr 24 '17 at 19:12
  • @ilkkachu Exactly the same on my computer with Debian 8. – rustyhu Apr 25 '17 at 17:08

It's not true that the system has nothing to do if no user level process is running. The system has a bunch of kernel threads, which the kernel itself has started. They are mostly sleeping, but periodically wake up to do their task. Kernel threads execute only kernel space code, i.e. they don't have any user level memory mappings. They are separate processes in that they are independently scheduled and have unique process ids.

If you run ps aux, you can recognize the kernel threads by the square brackets surrounding the thread name.

  • You are right. I tried myself on my notebook computer, in Debian 8, and I saw these kernel processes with name surrounded by square brackets in ps output. – rustyhu Apr 25 '17 at 16:09

The system does not have any process running. So, no busy loop like you have written (that would have 100% CPU). Interrupts could still be handled by the kernel, but there is no process. The CPU would be idle.

The details can be found here in the source of kernel_init(), the program is executed similar to execve(). That also means that execution does not return (see execve(3p)).

  • Yes, I should have written like while (1) { sleep(1); } – rustyhu Apr 24 '17 at 16:44
  • Yes, you probably mean code more like exit (0);. – Ned64 Apr 24 '17 at 16:46
  • indeed; sleep 1 is not idle; it's watching the clock to see whether it's yet time to wake up. – DopeGhoti Apr 24 '17 at 16:50
  • 4
    Don't know if it helps, but I tried. I loaded /bin/sh with init=/bin/sh and exited when I had the prompt. The kernel panics and cpu (judging from the noise of the fan) went to 100%. Same with a VM, htop gives cpu usage for the VM at 100%. – resc Apr 24 '17 at 17:20
  • @resc Thanks for trying, did not really fit into my work schedule :-) – Ned64 Apr 24 '17 at 17:51

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.