28

Apart from upgrading the kernel, are there any changes to a Linux system that require a reboot? I know there are situations where a reboot makes things easier, but are there any that cannot be accomplished except with a reboot?

To clarify: I'm thinking of a typical desktop or server system that isn't suffering from a hardware malfunction.

Improve this question
5
  • 3
    every thing can be done without rebooting. even changing the kernel can be done using ksplice so you can hot swap your kernel. The only thing you need to take into account is the fact making everything without rebooting can be very complex
    – Kiwy
    Apr 4, 2014 at 8:39
  • 4
    Your question is very broad, because "Linux system" can mean many very different things.
    – Zrin
    Apr 4, 2014 at 9:02
  • Also "any changes" can mean quite a lot of different situations. Is recovery from failed hard drive that is part of an MD mirror such a change? If yes, then - unfortunately - it will sometimes require a reboot, because for example some HDD failures (on some HDD controllers) are able to make the system unresponsive. But you are probably not asking about such "changes" ...
    – Zrin
    Apr 4, 2014 at 9:11
  • 3
    @Kiwy Technically ksplice doesn't change the kernel. Ksplice allows a running kernel to be patched, while it is running. You might be thinking of kexec, which allows a new kernel image to be loaded "over" a running kernel in memory.
    – Thomas Nyman
    Apr 4, 2014 at 10:09
  • This reminds me, windows XP (I never went beyond) never shuts up about restarting even if it just updated IE8 (or whatever number) which hasn't been opened for 4 years, since the installation of Windows and hence the need to download a browser.
    – Shahbaz
    Apr 5, 2014 at 18:16

3 Answers 3

Reset to default
44

A couple of things come to mind:

  • Recover from a kernel panic

    A kernel panic, by definition, cannot be recovered from without restarting the kernel.

  • Recover from hangs which leave you without terminal access

    If the system is unresponsive and you're stranded without a way to issue commands to recover, the only thing you might be able to do is to reboot. Usually, you'd want to avoid manual power cycling. For these kinds of situations, the Linux kernel has Magic SysRq support which can be used to reboot the machine in an emergency.

    As long as CONFIG_MAGIC_SYSRQ option has been enabled in the kernel configuration, and the kernel.sysrq sysctl option is enabled, you can issue commands directly to the kernel with magic SysRq key combinations:

    Note that Alt+SysRq below means press and hold down Alt, then press and hold SysRq (typically the PrintScrn key).

    1. Alt+SysRq+r: regain control of keyboard
    2. Alt+SysRq+e: send SIGTERM to all processes, except init, giving them a chance to terminate gracefully
    3. Alt+SysRq+i: send SIGKILL to all processes, except init, forcing them to terminate
    4. Alt+SysRq+s: attempt to sync all mounted filesystems
    5. Alt+SysRq+u: remount all filesystem read-only

    6. Alt+SysRq+b: reboot, or

      Alt+SysRq+o: shutdown

    A mnemonic for the magic SysRq key combinations to attempt a graceful reboot is:

    "Reboot Even If System Utterly Broke"

    For headless servers, there's even an iptables target enabling remote SysRq sequences over a network.

  • Recover from unbootable state

    If the system has already been brought to a state where a regular boot is not possible (e.g. as a result of a failed system upgrade, corrupt filesystem etc.), then the only way to access a recovery console on the system might be to reboot using appropriate boot-time options.

  • Change boot-time kernel parameters

    Some kernel parameters (e.g. audit to enable / disable kernel auditing) can only be set when the kernel is loaded at boot-time.

Improve this answer
5
  • 3
    "Reboot Even If System Utterly Broke" I'm favoriting this question just in case, but I don't think I'll ever forget that.
    – embedded.kyle
    Apr 4, 2014 at 13:16
  • 1
    It is possibly worth noting you can get out of a panic using a kexec and avoid a complete reboot. This also applies equally to the getting out of unbootable state point. (they are not the same thing by any means, at least on an x86 system). However +1 for the rest of this answer.
    – Vality
    Apr 4, 2014 at 13:55
  • @Vality Thanks for your comment. If kexec entails a reboot depends perhaps to a certain extent on ones point of view. The kdump documentation for instance describes kexec-on-panic as a reboot which preserves the system kernel's memory image. As for the point about unbootable state, I also considered things like bootloader misconfiguration (e.g. failure to load kernel in the first place), where kexec does not help. Given the nature of the question, I think some difference of opinion regarding semantics is unavoidable.
    – Thomas Nyman
    Apr 4, 2014 at 16:37
  • @ThomasNyman Thank you for your detailed response, looking at the question you are correct I feel. I think talking about kexec will probably just needlessly complicate things for the target audience or this question. And you also make a good point regarding boot-loader errors.
    – Vality
    Apr 4, 2014 at 16:42
  • I had never noticed that little SysRq written under print screen! This is awesome. I wish I had known this when I was learning kernel module programming!
    – Shahbaz
    Apr 5, 2014 at 18:20
2

There are two times I can think of where I would want to reboot:

  1. When I need to make sure that the system can boot up in the proper state.

    I once worked on a system that had some daemon configured while it was running. After it ran for a few years, a power failure caused it to reboot, but the daemon was not part of the startup process and nobody had a clue how it had been configured years earlier. The system was down for days while we figured out how to reconfigure it.

    Actually rebooting is the only way to know for sure that your system will restart properly after a power failure.

  2. When a system library has been updated.

    Let's say that a major security flaw has been discovered in a library that's shared with many apps/servers on the system. You can update the library without rebooting, but how many processes are still running with the insecure library loaded? You can painstakingly restart anything using the old library (if you can figure it out), but that is error prone and can take longer than just rebooting.

    Rebooting is the best way to be sure that all running processes are not still using the old, buggy library.

Improve this answer
8
  • There are better ways to find all binaries depending on a certain library if you use a good package manager. revdep-rebuilt from Gentoo comes to mind.
    – Spidey
    Apr 5, 2014 at 0:34
  • 1
    @Spidey: Once you rebuild those binaries, how do you ensure that there are no old processes running with the buggy library?
    – Gabe
    Apr 5, 2014 at 2:30
  • 1
    How do you know which daemons have the offending libraries loaded?
    – Gabe
    Apr 5, 2014 at 2:48
  • 1
    @Gabe You could for instance check which processes have the libraries mapped to their memory space using lsof before you upgrade the libraries.
    – Thomas Nyman
    Apr 5, 2014 at 11:32
  • 1
    @Gabe Sure, and while I agree that that's a perfectly good reason to reboot, the OP is explicitly not asking in which cases a reboot is more conventient, but when a reboot is absolutely necessary.
    – Thomas Nyman
    Apr 5, 2014 at 19:44
0

If you mean planned changes in the software configuration and assume perfectly working hardware (I haven't seen such yet) and bug-free software (you know ...), then only a bug in the kernel or a driver would force you to reboot. :)

Other than that ... I'm not sure if it would be possible to replace init without switching to single user mode and doing some magic which is essentially not much different than a reboot.

Improve this answer

You must log in to answer this question.

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