Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Software Upgrades Linux

Reboot Linux Faster Using kexec 59

Posted by timothy from the recurse-yourself dept.
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."
This discussion has been archived. No new comments can be posted.

Reboot Linux Faster Using kexec More

Reboot Linux Faster Using kexec

Comments Filter:

  • pfft. (Score:5, Funny)

    by hookedup ( 630460 ) on Wednesday May 05, 2004 @09:47AM (#9062806)
    I get paid by the hour. So how would this help me? :)

    • Get Windows (Score:5, Funny)

      by Anonymous Coward on Wednesday May 05, 2004 @09:52AM (#9062848)
      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.

  • Init scripts... (Score:4, Interesting)

    by ErisCalmsme ( 212887 ) on Wednesday May 05, 2004 @09:59AM (#9062903) Homepage Journal
    For me what takes the longest isn't the bootloader, it's the starting and stopping of services. This is still cool though.
    • how many services do you actually need on a workstation?
      • Well my point wasn't that it takes long for my laptop, my point was that starting and stopping services when I reboot takes longer than grub, where the total reboot time = (time it takes for the bios and grub) + (time it takes to stop services) + (time it takes to start them again)

    • Re:Init scripts... (Score:5, Insightful)

      by phaze3000 ( 204500 ) on Wednesday May 05, 2004 @10:09AM (#9062981) Homepage
      You're quite right, the starting and stopping of services takes much longer than the bootloader.

      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)

      by ggeens ( 53767 ) <ggeens AT iggyland DOT com> on Wednesday May 05, 2004 @10:20AM (#9063108) Homepage Journal

      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.)

      • I see what you guys mean about the BIOS, I just mentioned the bootloader 'cause it's the sub-title of the article, i.e. "Eliminate the bootloader for greater uptime"

        It should probably say "Eliminate the BIOS for greater uptime" ?

      • Speeding up boot (Score:5, Insightful)

        by 0x0d0a ( 568518 ) on Wednesday May 05, 2004 @04:21PM (#9067138) Journal
        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.
    • For me what takes the longest isn't the bootloader, it's the starting and stopping of services. This is still cool though.

      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)

      by Fweeky ( 41046 )
      Try using a system which doesn't kill each service one by one in a serial manner; the difference between shutdown speed in, say, Slackware or FreeBSD compared with RedHat and friends is quite significant. You'll have to learn to live without the fancy green [OK]'s though :)
    • Yes, I agree. What really bugs me is that if my ethernet connection isn't currently activated it takes several minutes before it gives it a [failed] and moves on. O.o
    • So dont start and stop them. Just close the lid and let it suspend to disk. I think I had over 100 days uptime on my laptop because of that at one stage. (Course, it does mean you need a laptop with decent APM support, or for ACPI you need to use the swsusp patch to have linux do the save/restore as ACPI itself cant do it).

  • Avoid BIOS (Score:4, Informative)

    by crow ( 16139 ) on Wednesday May 05, 2004 @10:06AM (#9062956) Homepage Journal
    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.

    • Re:Avoid BIOS (Score:4, Informative)

      by cyb97 ( 520582 ) * <cyb97@noxtension.com> on Wednesday May 05, 2004 @10:07AM (#9062965) Homepage Journal
      usually the slowest part of booting a scsi-kernel is "waiting for scsi-devices to settle". Which is usually set to 15s for quite a few drivers in the kernel. Bumping that down to a resonably low number like 2-3 s (usually enough for modern devices, would skimp 10-13s of you boot-time ;-)
    • Yeah the thing that kills my reboot time on x86 boxes is definately the BIOS, in particular the "Verifying DMA Buffers" check that cannot be turned off and adds about 20 seconds to the boot time.
    • Not just the SCSI cards but those **** Intel EExpress cards that wait for 4 seconds for ctrl-s before continuing the boot.

      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)

    by Anonymous Coward
    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.

  • Quicker reboots? (Score:3, Informative)

    by sweede ( 563231 ) on Wednesday May 05, 2004 @10:40AM (#9063407)
    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.
    • It would be a trivial task to write a wrapper script that automates stopping processes and unmounting partitions. I bet somebody already has.
    • Try rebooting on a server like a HPaq DL380. The BIOS portion of the boot is 4 times longer than the linux portion. My desktop with SATA is about equal, so kexec would still speed that up by a factor of two.

    • Re:Quicker reboots? (Score:3, Informative)

      by Marillion ( 33728 )
      Perhaps something like, dropping to run level 1 first, then remount all drives as readonly.

      # init 1
      # mount -o remount,ro -a
      # kexec ...

  • Sounds great, but... (Score:5, Insightful)

    by You're All Wrong ( 573825 ) on Wednesday May 05, 2004 @10:49AM (#9063537)
    $ 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.

  • Nice, but not critical. (Score:4, Funny)

    by Blackknight ( 25168 ) on Wednesday May 05, 2004 @11:21AM (#9063955) Homepage
    Yeah, that 90 seconds to reboot a server is killing me.
    • [ok, I get the joke... but]

      well, if you're chasing 5 nines, you only get 315 seconds downtime a year.
      • If you're chasing that kind of reliability the way forward is redundant machines behind reliable load-balancing of some sort, not fudging about with new and relatively untesed 'fast reboot' code which could well get up and bite you in the back-end server at any time..

  • Useful for other reasons than speed (Score:5, Interesting)

    by Anonymous Coward on Wednesday May 05, 2004 @01:41PM (#9065568)
    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 :)

  • What's taking it so long? (Score:4, Interesting)

    by Brandybuck ( 704397 ) on Wednesday May 05, 2004 @03:32PM (#9066715) Homepage Journal
    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?
    • You are right. Something is decidedly wrong on your system. It takes me, IIRC, under a second to go from "bootloader screen" to "kernel spitting out init data". It is definitely not twenty seconds.

      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...
      • I'm a bit skeptical that running the init scripts in the background will speed things up appreciably. On a box with only a single system disk, spawning a lot of processes at once is only going to thrash the disk and make all of the startup *slower*, especially if those services all start reading their config files, prepping their application caches, etc...

        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
  • 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. YM
    • Yeah, I totally identify with this. Reboots were still a pretty infrequent thing for me, and I could use programs like screen to keep my context around if I was just logging off for an evening.

      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)

    by m4k3r ( 777443 )
    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.

  • Remote Systems (Score:1, Offtopic)

    by osewa77 ( 603622 )
    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 o

  • kloader (Score:2, Interesting)

    by Ushakov ( 57403 )
    In NetBSD kloader(4) [gw.com] does a similar job. It is used on HPC and game console ports.

Slashdot Top Deals

"May your future be limited only by your dreams." -- Christa McAuliffe

Close