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."
I get paid by the hour. So how would this help me? :)
You're paid by the hour and use Linux?!?!?!. What you need is Windows, and make sure you don't have a firewall or a virus checker program. You'll greatly increase your billable hours.
For me what takes the longest isn't the bootloader, it's the starting and stopping of services. This is still cool though.
Chaos is Divine *
well kexec is brought to you buy the same guys that invented ctrl+alt+del. I guess you can think of it as the next-generation of the three fingered salute ;-).
Rebooting a box that has SCSI drives means that the BIOS does a scan of the SCSI bus that takes a while, and then the new kernel does the same thing. That's the slowest part of my boot process, and it looks like kexec will bypass the BIOS half of it.
The boot loader spends most of its time waiting for the user to press a key, so they can enter custom boot parameters. If you set the timeout to 0 in LILO or GRUB, loading the kernel happens almost instantly.
The BIOS startup routine is longer, especially if you have a SCSI card. (I have 2 of those in my machine, and they account for most of the wait during startup.)
WWTTD?
If you read the article, it says that kexec doesnt do a normal,clean shutdown, so you have to stop all running programs and unmount all partitions before running kexec to do a reboot.
When i boot into linux, it takes longer to start up services than it does to go through the BIOS, SATA raid controller BIOS, grub's 3 second time out, and the loading of the linux kernel (before initd takes over).
however, this program is still in ints infancy and no doubt someone will create an initd that can utilize kexec in a run level for rebooting without a full shutdown. But I dont think it will be that much quicker.
I follow the SDK and GDN principles.. Spelling Dont Kount, Grammer Dont Neither
$ 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.
Yeah, that 90 seconds to reboot a server is killing me.
While there is a marginal speedup in skipping the BIOS startup, the main benefit for me is the ability to choose which kernel to boot remotely. I don't have physical access to my colocated system and permanently setting GRUB to boot a new kernel is a bit scary. With kexec I can choose which kernel to boot from ssh. If it doesn't work out I don't have to pay the colo people to reinstall the box. They just hit the reset button :)
I normally use FreeBSD. But recently I took a Linux device drivers class. The first thing I noticed was the extremely slow booting of Linux. Why?
Under FreeBSD it takes about one second from the boot manager handing off to the root partition to start seeing device probing messages. But under Linux the same thing takes about twenty seconds. From appearances, it seems that the root partition LILO is merely loading the kernel, but there's no way that should take twenty seconds. Can it?
Don't blame me, I didn't vote for either of them!
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
You mean like BSD init + rcorder, which predates Gentoo.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
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.
In NetBSD kloader(4) does a similar job. It is used on HPC and game console ports.