Reading one of Stephen's excellent replies, I was wondering what differences are between

When the operating system shuts down. ...


When the kernel shuts down, ... (... I’m considering that the variant which uses an external command to shut down isn’t the kernel)


Is "the variant which uses an external command to shut down" "when the OS shuts down" or "when the kernel shuts down"?

What does "I’m considering that the variant which uses an external command to shut down isn’t the kernel" mean in other words?

Does system call reboot() reboot the OS or kernel?

Does command reboot reboot the OS but not the kernel?


  • Deleting the reference and link to the reboot() documentation, the most fundamental part of the sentence, from the last quote is utterly inexplicable to me. Dec 18, 2018 at 5:39
  • That's because I don't quite understant what the original means. If you do, thank you in advance to tell me what that means.
    – Tim
    Dec 18, 2018 at 5:43
  • 2
    I think you should just quote accurately. Dec 18, 2018 at 6:03
  • I would think that the OS shuts down, then tells the kernel to shutdown, and when the kernel has shutdown, it will tell the hardware to shutdown (power off). If you skip a step, then things are not shutdown properly. Dec 18, 2018 at 13:19

2 Answers 2


The post you have quoted from actually says this:

When the kernel shuts down, or reboots, it doesn’t care about processes and doesn’t kill them (see reboot() for details; I’m considering that the variant which uses an external command to shut down isn’t the kernel).

Your selective editing has spliced together unrelated sentences to create a false impression.

The part you have kept (from after the semicolon) relates to the part immediately before the semicolon (which you have deleted). That is, the variant of reboot() which uses an external command to shut down (LINUX_REBOOT_CMD_RESTART2, in the documentation, which was linked) is being excluded from consideration for Stephen's purposes.

The first quote is not relevant.


He seems to be noting a difference between the kernel itself, and the rest of the operating system, the user-space constructs built on top of the kernel.

When you shut down the system with /sbin/reboot or equivalent (which in turn calls systemd or some init scripts or something), it does more than just ask the kernel to shut down. The user-space tools are the ones that do almost all the cleanup, like unmounting filesystems, sending SIGTERM to other processes ask them to shut down, etc.

If, instead, you go and call the reboot() system call as root directly, then none of that cleanup happens, the kernel just does what it's told to do and shuts down right away (possibly restarting or powering down the machine). The man page notes that reboot() doesn't even do the equivalent of sync(), so it doesn't even do the kinds of cleanup that could be done within the kernel (where the filesystem drivers and I/O buffers reside.)

As an example from the man page:

       (RB_AUTOBOOT, 0x1234567).  The message "Restarting system." is
       printed, and a default restart is performed immediately.  If
       not preceded by a sync(2), data will be lost.


Does system call reboot() reboot the OS or kernel?

It asks the kernel to shut down or reboot, the OS goes down with it.

Does command reboot reboot the OS but not the kernel?

It asks user-space processes to shut down, does other cleanup, and only then asks the kernel to shut down or reboot.

The reboot() system call has a mode (LINUX_REBOOT_CMD_RESTART2) that is described as "using a command string". However, it doesn't mean a user-mode command, but one internal to the kernel, and one that isn't even used on x86.

Note that while we're considering the distinction between the kernel and the OS-on-top-of-the-kernel, you could in principle reboot just the OS but keep the kernel running. You'd need to clean up everything set up by the userspace and kill other userspace processes, then restart init to bring everything back up again instead of asking the kernel to reboot. That might not be very useful though, and it would be hard to reliably reset all state left in the kernel (you'd need to manually reset all network interfaces, clean up iptables rules, reset RAID and loop devices, etc. etc. There's a good chance of missing something that might then bite back afterwards.)

  • 2
    That’s exactly the distinction I was trying to make, thanks for taking the time to write it up! Dec 18, 2018 at 10:31
  • Thanks. "An added confusion here is caused by the fact that the reboot() system call appears to be capable of running a process to do the restart (however that works)" What confusion is it? Do you mean that the command string given in arg is run before the kernel is shutdown, so may do some cleanup?
    – Tim
    Dec 19, 2018 at 2:21
  • @Tim, yeah, basically that. If the command given to reboot() can do whatever it likes, just as any other userspace program, then it's not really true in that case to say that reboot() doesn't do any cleanup. (I've no idea how the reboot()-calling-userspace variant works, if there are any limitations.) But the other reboot() variants don't do any cleanup, that's for sure.
    – ilkkachu
    Dec 19, 2018 at 8:27
  • Thanks. unix.stackexchange.com/questions/489995/…
    – Tim
    Dec 19, 2018 at 20:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .