mjhjmtu

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.

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.

  
  

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.

   
   

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.