This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Tools & Utilities

Reboot like a racecar with kexec

By David Pendell on October 16, 2008 (9:00:00 AM)

Share    Print    Comments   

If you have ever found yourself in the position of having to reboot quickly or several times, you know that it's not a very quick process, particularly if you have SCSI devices or other initialization-intensive system devices. A package called kexec can speed up your reboots -- if you understand the rules.

Kexec was originally intended for use by kernel and system developers who had to reboot several times a day. Soon, system administrators for high-availability servers found use for it as well. As systems get more and more advanced, and boot times get longer, end users can now benefit from it.

The system is simple, and consists of two parts: a kexec-enabled kernel and the kexec-tools package. Most modern kernels already support kexec functionality, but I haven't found a reliable way to test for kexec support in the kernel. My suggestion is to try it -- if it works, you have it. If not, you may have to compile a custom kernel to get it. As for the second part, you can get the kexec-tools software either from your distribution's repositories or from the kexec project page.

Before you can execute the commands, there are a few things you should know. When you load a new kernel by running kexec you are overwriting the existing kernel with the kernel you specify. While this has the effect of rebooting the system quickly, it also skips the process that resets all of your hardware to a "clean" state, which can have some unpredictable consequences depending on the hardware that you use. For example, the video card on my system is an old Nvidia GeForce2 Go, and I had been using the legacy driver from Nvidia for it. After using kexec to reboot, the video never worked correctly. When I switched to the open source driver, the video came up just fine. Outcomes like this may be as varied as the kinds of hardware that exist. You just need to be aware of the possibility of problems in case something happens that you don't expect.

You also need to know that kexec only reboots the kernel -- it does not take care of any cleanup such as shutting down applications or unmounting disks. We are going to set up a script that will take care of the whole process.

I put this script in the /etc/init.d/reboot file in Ubuntu. The best location will vary depending on your distro. I do recommend making this part of your system reboot procedure, however. Running it as a standalone script might have unexpected results. When I first experimented with kexec, I found that running the kexec commands from a command line would produce behavior that was sometimes erratic and sometimes left my system in a temporarily unusable state.

In the following code, the changes that I made to the original reboot file are highlighted.

do_stop () { UNAMER=`uname -r` # this checks the version of the kernel #just to save typing #This just puts all of the parameters for loading in one place KPARAMS="-l " # tells kexec to load the kernel # --append tells the kernel all of its parameters # cat /proc/cmdline gets the current kernel's command line KPARAMS=$KPARAMS"--append=\"`cat /proc/cmdline`\" " # this tells the kernel what initrd image to use KPARAMS=$KPARAMS"--initrd=/boot/initrd.img-$UNAMER " # this tells the kexec what kernel to load KPARAMS=$KPARAMS"/boot/vmlinuz-$UNAMER" # Message should end with a newline since kFreeBSD may # print more stuff (see #323749) log_action_msg "Will now restart" if [ -x `locate kexec | grep sbin` ]; then # check for the kexec executable kexec $KPARAMS # load the kernel with the correct parameters sync # sync all of the disks so as not to lose data umount -a # make sure all disks are unmounted kexec -e # reboot the kernel fi #This next line should never happen. reboot -d -f -i }

I use the UNAMER and KPARAMS variables to make the first kexec line is easier to read. The if statement just checks to make sure that there is a kexec command in the expected place and that it can be executed. Kexec $KPARAMS loads the kernel with the command line for the current kernel, with the matching initrd and vmlinuz files. You want to load the new kernel with the current command line because it is not going to get a command line from a bootloader. Also, you have to use the vmlinuz image because kexec doesn't support compressed images. The sync command simply makes sure that all of the data that might be cached is written to the disk; remember, kexec doesn't care about the state of the disks, but if you boot a new kernel without properly handling the disks, you will run into problems. The umount -a command then makes sure that all of your disks are not open for business, and kexec -e reboots the computer.

Unless you have a driver issue you should be presented with your normal login when the system comes back up. If you aren't, you might be able to log in with SSH or a serial terminal and shut your system down properly. If not, you will probably have to hard boot. When you get control over your computer again, check all of the commands and their syntax -- you may have a typo. If not, you are probably looking at a driver issue. Look at /var/log/messages and the output of the dmesg command; they may give you a clue. You can also search the project's message boards about the hardware and distro that you are using. At last resort, if you have an idea of what hardware the is causing the problem, contact the development team in charge of the driver for that hardware. They might be interested in the problems that you are having, and if so, this would be your chance to contribute.

If you understand the possible problems, kexec has the potential to dramatically speed up reboots. In the world of modern computers, every little bit helps.

David Pendell has been working with computers for the last 23 years in a variety of capacities, including for programming and audio and video processing. He has been using Linux since Red Hat 5.1 and has used a variety of distros.

Share    Print    Comments   

Comments

on Reboot like a racecar with kexec

Note: Comments are owned by the poster. We are not responsible for their content.

Reboot like a racecar with kexec

Posted by: Anonymous [ip: 83.44.164.91] on October 16, 2008 11:47 AM
really nice.

My systems ask for the kernel as the first parameter of kexec (ubuntu hardy 8.04).

And some questions:
1-why doing all the uname if you don't know if kexec exists? Perhaps is better to have the if clause before everything else
2.using the locate could be very time consuming (perhaps you have 4 TB with 1 trillion files), perhaps is better to use "which" or tu check directly on /sbin /usr/sbin and /usr/local/sbin

regards!

#

Reboot like a racecar with kexec

Posted by: Anonymous [ip: 66.151.59.138] on October 16, 2008 01:32 PM
""" if [ -x `locate kexec | grep sbin` ]; then # check for the kexec executable"""
That is very poor style. What if kexec is in the locatepath but is NOT in the PATH
variable? Then your kexec commands fail.

You seriously might want to update the article with something like this:
if [ -x "`which kexec`" ]; then

#

Re: Reboot like a racecar with kexec

Posted by: Anonymous [ip: 4.227.198.146] on October 18, 2008 03:56 AM
Locate is part of the updatedb system that uses a database the updates during a cron job, usually. Since locate searches a database on NOT the files on the disk, it shouldn't matter if it is in the path or not. It is also quite fast and reliable provided that it is allowed to run regularly.

#

Re(1): Reboot like a racecar with kexec

Posted by: Anonymous [ip: 24.57.109.194] on October 18, 2008 05:12 AM
To Anonymous [ip: 4.227.198.146]:
I'm not the person who complained about your (ab)use of locate. However, (s)he is completely right. You don't understand. Let's say you don't really have kexec installed. But a random/old/whatever copy of kexec just happens to be sitting in /opt/blah/kexec for no apparent reason. But /opt/blah/ isn't in your path. The locate command might find the file just fine. But when you actually go to RUN kexec, it'll fail because it's not in your path.

Locate might also yield false positives, such as /home/root/how_to_use_kexec.htm. It'd be kind of hard to run such a document as a command.

The which command, on the other hand, will ONLY check your path and will ONLY return executables with the right permissions. That's exactly what you want. If the which call succeeds, your kexec call should succeed as well (barring the various nasty problems you've already named).

#

Re(1): Reboot like a racecar with kexec

Posted by: Anonymous [ip: 217.125.193.134] on October 20, 2008 09:29 AM
it's fast to search on every drive mounted in your system, but locate is very time consuming if you have 4TB with 1 trillion files (it can take up to 1-2 minutes). Using which, or searching manually in /sbin /usr/sbin /usr/local/sbin is a lot faster.

regards,

#

Reboot like a racecar with kexec

Posted by: Anonymous [ip: 134.67.6.11] on October 16, 2008 05:01 PM
> Most modern kernels already support kexec functionality, but I
> haven't found a reliable way to test for kexec support in the kernel.
> My suggestion is to try it -- if it works, you have it.

grep CONFIG_KEXEC=y /boot/config-`uname -r` && echo yes || echo no

#

Re: Reboot like a racecar with kexec

Posted by: Anonymous [ip: 4.227.198.146] on October 18, 2008 03:50 AM
That's fine if you have a system that keeps the config for the currently running kernel. What I wanted was a way to glean the support information from the running kernel. Modern kernels support keeping the config in the kernel, but Ubuntu, the system that I use most, doesn't enable that option when compiling their kernels. I want something that is universal and foolproof.

#

Re(1): Reboot like a racecar with kexec

Posted by: Anonymous [ip: 15.195.185.83] on October 20, 2008 12:53 PM
Ubuntu does not provide it as other standard kernels in /proc/config.gz?

#

Reboot like a racecar with kexec

Posted by: Anonymous [ip: 192.168.1.81] on October 17, 2008 08:02 AM
It appears to me that this works with 2.5 kernels, not 2.6.
please correct me if im a wrong..

#

Re: Reboot like a racecar with kexec

Posted by: Anonymous [ip: 4.227.198.146] on October 18, 2008 03:43 AM
No, I wrote this article using a machine that boots 2.6. You shouldn't have any trouble. Besides, the 2.5 kernels were just the development versions of 2.6.

#

Reboot like a racecar with kexec

Posted by: Anonymous [ip: 81.193.164.208] on October 17, 2008 10:13 AM
Thanks, works fine in gentoo, now i have a fast reboot ;) and about fast boot ?

#

Re: Reboot like a racecar with kexec

Posted by: Anonymous [ip: 4.227.198.146] on October 18, 2008 03:59 AM
I want that too. I have been watching a project for a while now that promises this, but it is VERY alpha. If you want to look into it, go to www.coreboot.org. Make sure that you try this with an expendable motherboard as you could fry it just as easily as making it boot faster.

#

Reboot like a racecar with kexec

Posted by: Anonymous [ip: 85.8.66.254] on October 19, 2008 11:09 AM
for me it works like a charme on version 2.6. no problems here. its amazing and very fast, an excellent solution for especially webserver installations. thx 4 the hint. Jordan from http://www.webdirekt-online.de

#

Reboot like a racecar with kexec

Posted by: Anonymous [ip: 62.111.200.202] on October 24, 2008 09:39 PM
Original one didn't work for me, it uncited cmdline. Also I've got bzImage not vmlinuz. This do_stop() works
UNAMER=`uname -r`
CMD=`cat /proc/cmdline`
KPARAMS="-l " # tells kexec to load the kernel
KPARAMS=$KPARAMS"--initrd=/boot/initrd.img-$UNAMER "
KPARAMS=$KPARAMS"/boot/bzImage-$UNAMER"
KPARAMS="$KPARAMS --append=CMD"
log_action_msg "Will now restart"
if [ -x /sbin/kexec ]; then
/sbin/kexec $KPARAMS
sync
umount -a
kexec -e
fi

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya