Reboot Linux Faster Using kexec 59
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."
pfft. (Score:5, Funny)
Get Windows (Score:5, Funny)
Re:I thought... (Score:2)
Re:I thought... (Score:3, Funny)
Init scripts... (Score:4, Interesting)
Re:Init scripts... (Score:1)
Re:Init scripts... (Score:1)
Re:Init scripts... (Score:5, Insightful)
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.
BIOS (Score:5, Informative)
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.)
Re:BIOS (Score:1)
It should probably say "Eliminate the BIOS for greater uptime" ?
Speeding up boot (Score:5, Insightful)
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.
Re:Speeding up boot (Score:2, Informative)
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 mean like in Gentoo?
RogerYou mean like in FreeBSD? (Score:2, Informative)
Re:You mean like in FreeBSD? (Score:1)
Cheers,
Roger
You mean like in NetBSD? (Score:2)
Is this the end of this journey of discovery? (Score:2)
Yes, this is the end. (Score:1)
Paralising init (Score:2)
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.
Re:Init scripts... (Score:2)
True for me too, but if I were developing the kernel I would probably just reboot to single user mode.
Re:Init scripts... (Score:3, Informative)
Re:Init scripts... (Score:1)
Re:Init scripts... (Score:2)
Avoid BIOS (Score:4, Informative)
Re:Avoid BIOS (Score:4, Informative)
Re:Avoid BIOS (Score:2)
Re:Avoid BIOS (Score:1)
Or, on cheaper hardware (like mine), those IDE controllers scanning the bus for ATA100 devices. I have an el-cheapo whitebox that takes almost 2 minutes to get to the GRUB prompt.
Equivalent (Score:1, Informative)
Quicker reboots? (Score:3, Informative)
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.
Re:Quicker reboots? (Score:2)
Re:Quicker reboots? (Score:2)
Re:Quicker reboots? (Score:3, Informative)
Sounds great, but... (Score:5, Insightful)
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.
Famous last words: (Score:5, Funny)
Re:Sounds great, but... (Score:1)
List *your* uptime! (Score:2)
Re:List *your* uptime! (Score:2, Insightful)
I know there have been several vulnerabilites in the linux kernel in that time. (search google for mremap).
Nice, but not critical. (Score:4, Funny)
Re:Nice, but not critical. (Score:3, Insightful)
well, if you're chasing 5 nines, you only get 315 seconds downtime a year.
Re:Nice, but not critical. (Score:2)
Useful for other reasons than speed (Score:5, Interesting)
Re:Useful for other reasons than speed (Score:1)
The Bios and other hardware init stuff on our Dell Servers takes (compared to the speed of the machines) ages.
Re:Useful for other reasons than speed (Score:2)
The faster the machine, the slower the POST and floppy drive. It seems to be the case most of the time since the first XT running faster than 4 MHz.
What's taking it so long? (Score:4, Interesting)
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?
Re:What's taking it so long? (Score:3, Informative)
Now, the time spent sitting in init scripts when a desktop could be brought up much faster and initscript loading continued in the background is an arguable issue...
Re:What's taking it so long? (Score:2)
My Windows XP laptop starts up this way, and even after optimizing the disk, startups are slow because of all of the startup programs trying to initializ
It's not the kernel boot time (Score:1)
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. YM
Re:It's not the kernel boot time (Score:2)
Windows suspend/standby is worthless for this; when the network drivers go to sleep Winsock kills all your connections. (Which, by the way, is a violation of the OSI stack architecture.) And my Win XP laptop has proven to be pretty unreliable after about 2-3 suspend/resume cycles (not to mention the consistent BSOD f
Experimental kernals... (Score:2, Insightful)
Remote Systems (Score:1, Offtopic)
kloader (Score:2, Interesting)