Slashdot Mirror
Reboot Linux Faster Using kexec
An anonymous reader writes "Even if your work doesn't require you to reboot your Linux machine several times a day, waiting for a system to reboot can be a real drag. Enter kexec. Essentially, kexec is a fast reboot feature that lets you reboot to a new Linux kernel -- without having to go through a bootloader. Faster reboot is a benefit even when uptime isn't mission-critical -- and a lifesaver for kernel and system software developers who need to reboot their machines several times a day. Kexec is currently available on the x86 32-bit platform only."
What takes even longer though, and is avoided by use of kexec, is all the BIOS stuff. This can take an age, particularly with SCSI controllers in my experience.
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
$ uptime
17:44:44 up 439 days, 7:50, 7 users, load average: 1.07, 1.02, 1.00
I think I'll install it some time in 2005, maybe.
Actually it's not so great - if you're mucking around with different kernels etc. then what you really want is virtualisation, not fast reboots. VMWare, or Bochs, or whatever. At least that's what I'd prefer, YMMV.
YAW.
Your head of state is a corrupt weasel, I hope you're happy.
[ok, I get the joke... but]
well, if you're chasing 5 nines, you only get 315 seconds downtime a year.
The biggest gain I can think of would be moving from an initscript system in which all services are serially numered to one where dependencies are expressed with a directed acyclic graph. All you have is "X depends on network being up" "cups depends on network being up", etc.
You could even leave in the old numbers (or *generate* the old-style numbers from the acyclic graph) and do serialized booting if necessary for troubleshooting.
There's no reason not to have as many service starting at once as possible, and several benefits.
* Boot time would decrease because Linux has a good disk scheduler and keeping more outstanding requests keeps the scheduler well-fed with requests to optimize the order of.
* Boot time would decrease because Linux service startups are not constantly hitting the disk. Some hit the network or the CPU. You want to keep a steady stream of requests to the disk running.
* User-percieved boot time would decrease because the first thing that the user generally cares about is the password dialog (and subsequently their desktop). With a DAG, a partial ordering of the boot sequence, the init system has the freedom to load X up as soon as possible and get the user to a password prompt, and continue loading less important things (ntp and the like, sendmail, etc) in the background.
May we never see th
uptime that high == insecure
I know there have been several vulnerabilites in the linux kernel in that time. (search google for mremap).
Sounds like just the thing for testing a newly compiled kernel without modifying the bootloader. I'd much prefer to test the kernel on the "real" system then some sort of virtualisation (VMware etc) using kexec. Much faster than accidentally screwing the system, trying to find a bootable cd etc.