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.
Ctrl+Alt+Del is the fastest way to reboot :)
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 *
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.
In 'Windos' terms, this is equivalent to the 'shift+restart' feature on earlier windows. You would press shift while hitting restart and it would only restart without rebooting the machine.
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!
I'm just curious -- anyone reading this that can beat the listed uptime?
May we never see th
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
but the setup time of my regular tools that makes rebooting such a drag.
I usually have 10-12 telnet sessions open, monitoring log files, machine load and application layer protocol network traffic for a couple of servers.
This takes an awful lot of time to set up. Not to mention IDE boot times, finding the right documentation and whatnot. Thank god I wasn't vulnerable to the newest and brightest Windows worm that got my whole company. Anything forcing me to boot my Debian box would really tick me off. YMMV.
20 minutes into the future
Some services spend quite a while waiting for things to happen, e.g. initilising a cd-rom drive.
Services that are independant could be started in parrell so that waiting for a cd-rom drive &co wouldn't slow the whole things down. e.g. I could load the cd-rom drive, networking and keyboard mapping, then while the cd-rom drive is still waiting for an interrupt start up apache.
thank God the internet isn't a human right.
You mean like BSD init + rcorder, which predates Gentoo.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
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.
As mentioned before, remote systems are where this utility would really shine. If there was a simple way to tell a kernel to reboot on error instead of locking up the system, then it'd be the perfect system for testing various kernels on a remote system. No need to call your colocation host and ask for a manual reboot! Again, there are projects being developed to reduce the imit time for Linux. On such systems, the relative speed of this approach wil be significant. And, yes, 150 seconds can be a lot of time to wait for a reboot.
Give credit to whom it is due: FreeBSD just borrowed the rcorder system from NetBSD.
Tarsnap: Online backups for the truly paranoid
I was hoping somebody would chime in saying NetBSD stole it from somewhere else. Something unexpected, like AcornOS or some such.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Luke Mewburn wrote the new rc.d system for NetBSD.
Tarsnap: Online backups for the truly paranoid
In NetBSD kloader(4) does a similar job. It is used on HPC and game console ports.
Another MStrolll spewing FUD I see. Don't see the point, considering that it is mainly linux developers who are looking at this post,and they'll know better than that.
Linux has given me uptimes of up to two months, and it would be longer if my
house had better wiring or if I had a UPS (Uninterruptable Power Supply).
In Windows, I have never gotten an uptime of more than a few days. And the only
day that I did not have an application crash was teh day I left the system
untouched for a day (well two days, but it somehow crashed on the 2nd day
anyways....)
Personally, I won't be using kexec that often since I like to leave my system
on as long as possible. I don't reboot often enough for my BIOS or kernel
loading times to make a difference. (init scripts, and the filesystem checks
that happen every 26 mounts, would benefit from a speed up of course, but
thats another topic.) In windows, I had to reboot so often that even if it had a
shorter loading time (it didnt for me) it would still be too long.
Even if Linux booting was forever slower than Windows, it would be paid off by
the fact that Linux stability is forever better than Windows...