Differences between revisions 20 and 21
Revision 20 as of 2008-11-16 16:19:30
Size: 8003
Editor: JustinBRye
Comment: rephrase, reshuffle, add kexec
Revision 21 as of 2008-11-16 16:52:08
Size: 7407
Editor: JustinBRye
Comment: auto-ToC
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
==== Introduction ====
Desktop workstations commonly tend to be rebooted more frequently than servers, and laptops more often than either. A few simple steps can do a lot to shorten the wait while the machine gets from power-on to login. Commonly used methods of speeding up the boot process include:
Line 5: Line 3:
 * using readahead to preload files from disk
 * using dash as /bin/sh
 * using sleep mode
 * using kexec
 * reordering boot scripts based on dependencies
 * parallelizing the launching of services
 * removing unnecessary services
 * changing your init levels and script ordering
----
Desktop workstations commonly tend to be rebooted more frequently than servers, and laptops more often than either. A few simple steps can do a lot to shorten the wait while the machine gets from power-on to login.
Line 15: Line 5:
==== Using readahead to load files from disk ====  [[TableOfContents(2)]]

== Using readahead to load files from disk ==
Line 24: Line 16:
==== Using dash as /bin/sh ==== == Using a faster system shell ==
Line 33: Line 25:
==== Using sleep mode ==== == Using sleep mode ==
Line 37: Line 29:
==== Using kexec ==== == Using kexec for warm reboots ==
Line 46: Line 39:
==== Reordering boot scripts based on dependencies ==== == Parallelizing init.d scripts ==
Line 48: Line 41:
From Lenny onwards, it is possible to [:LSBInitScripts/DependencyBasedBoot:reorder the boot scripts according to the script dependencies]. This allows the scripts to run in parallel during boot and shutdown, and has been measured to improve boot speed. From Lenny onwards, it is possible to [:LSBInitScripts/DependencyBasedBoot:reorder the boot scripts according to the script dependencies]. Some init.d scripts can then be launched in parallel during startup and shutdown, so that (for instance) the boot process won't have to stop dead while it waits for the Internet connection to come up. This can be especially important for slow ISPs, or slow DHCP servers!
Line 50: Line 43:
To enable this, install the package {{{insserv}}}, and use {{{dpkg-reconfigure}}} to activate it. To enable dependency-based boot-ordering, install the package {{{insserv}}}, and use {{{dpkg-reconfigure}}} to activate it.
Line 57: Line 50:
## All the init.d-related hints are together now, but they could still do with some sorting - JustinBRye This now makes it possible to activate startpar concurrent booting. To enable this, first reorder the boot using the provided dependencies (as above), and then use
Line 59: Line 52:
==== Parallelizing the launching of services ====

Some boot-time scripts can be launched in parallel, so that the boot process won't have to stop and wait for the Internet connection to come up. This can be especially important for slow ISPs, or slow DHCP servers!

From Lenny onwards, it is possible to do this with the System V init system by enabling dependency-based boot sequencing and activating startpar concurrent booting. To enable this, first reorder the boot using the provided dependencies (see above), and then use
Line 67: Line 55:
Line 69: Line 58:
==== Removing unnecessary services ==== == Reorganising init.d services ==
Line 77: Line 66:
==== Changing your init levels and script ordering ==== === Changing your init levels and script ordering ===
Line 79: Line 68:
## this should be de-HatRed-ified and incorporated into the above - JustinBRye ## this should be de-HatRed-ified and merged into the above - JustinBRye
Line 99: Line 88:
----

=
=== Interactive Boot Editor (sysv-rc-conf) ====
=== Interactive Boot Editor (sysv-rc-conf) ===
Line 105: Line 92:
==== Analyze the boot process ==== {{{
aptitude install sysv-rc-conf
}}}
Line 107: Line 96:
## expand === Analyzing the boot process ===
Line 111: Line 100:
==== Some related links ==== {{{
aptitude install bootchart bootchart-view
}}}

== Some related links ==

Desktop workstations commonly tend to be rebooted more frequently than servers, and laptops more often than either. A few simple steps can do a lot to shorten the wait while the machine gets from power-on to login.

  • ?TableOfContents(2)

Using readahead to load files from disk

The readahead package runs at boot and populates the kernel disk cache with the files that are going to be needed during boot. To activate it, install readahead, touch the file /etc/readahead/profile-once and reboot once. The profiling boot is very slow, and will tune the list of files loaded to match the list of files used during the profile run.

aptitude install readahead
touch /etc/readahead/profile-once

Using a faster system shell

By default, the standard system shell /bin/sh is provided by bash. Bash is very slow at startup, because it does quite a lot of things before it starts to process shell statements. During bootup, a lot of shell scripts are executed, and switching to a quicker shell has a noticeable impact. To switch /bin/sh to point at dash, install the package and use dpkg-reconfigure to enable it as the default system shell.

aptitude install dash
dpkg-reconfigure dash

Using sleep mode

It is also possible to take advantage of the system's swap space to obtain very fast booting via sleep mode. This can give a boot process that completes in as little as five seconds after BIOS initialization. However, using sleep mode may require nonfree hardware-specific setup utilities, and/or poorly documented kernel-patching voodoo; and you still need to wait for hardware initialization before swap becomes available.

Using kexec for warm reboots

When your system is performing a warm reboot rather than being powered on in the morning, there's a way to avoid the wait while your computer pointlessly checks and re-initializes its hardware. Rather than go through the BIOS and bootloader, your system can simply go to a low runlevel, load the new kernel image into memory, and come back up. This requires a kernel configured with CONFIG_KEXEC=y (standard for Debian kernels), and the package kexec-tools:

aptitude install kexec-tools

Using kexec can save a lot of time if you frequently need to do warm reboots to try a new /vmlinuz, but don't let it set itself up as the default restart-handler if you more often want to reboot into a different O.S. (that is, on dual-boot systems).

Parallelizing init.d scripts

From Lenny onwards, it is possible to [:LSBInitScripts/DependencyBasedBoot:reorder the boot scripts according to the script dependencies]. Some init.d scripts can then be launched in parallel during startup and shutdown, so that (for instance) the boot process won't have to stop dead while it waits for the Internet connection to come up. This can be especially important for slow ISPs, or slow DHCP servers!

To enable dependency-based boot-ordering, install the package insserv, and use dpkg-reconfigure to activate it.

aptitude install insserv
dpkg-reconfigure insserv

This now makes it possible to activate startpar concurrent booting. To enable this, first reorder the boot using the provided dependencies (as above), and then use

echo 'CONCURRENCY=startpar' >> /etc/default/rcS

to activate it.

Reorganising init.d services

It's quite possible that the services that are taking all the time to start are ones you don't need in the first place. This is particularly likely for neophyte users who have simply accepted every installation suggestion their chosen desktop environment task dragged in. What's needed is a way to distinguish between the services you really need and the ones you don't.

The problem is that documentation for free software is often not very novice-friendly; in particular, scripts in /etc/init.d may contain comments, but they don't provide anything resembling a standard --help option.

With most packages the init.d script name is the same as the package name, so you can find out about it by running apt-cache show <servicename>. If they aren't the same you can use dpkg -S /etc/init.d/<service> to get the name of the package that owns that file.

Changing your init levels and script ordering

The Debian system by default runs at [RunLevel:Runlevel:]/initdefault 2. This means that every service you have to wait for while booting gets started in their symlink order in the /etc/rc2.d directory or their settings in file-rc for init 2.

If you have some services that you rarely use, especially if they take a long time to start and stop like netatalk or databases and mud servers, just use update-rc.d to purge all of the symlinks with the force option, then re-create the symlinks in the rc2+n.d levels. (eg put databases you frequently use in run level 3/rc3.d and slower stuff you almost never use in run level 4/rc4.d.) You can then 'activate' these 'groups' by running init <n> (eg init 3 or init 4) as root, even from in X. The in-progress dbus system may help the activating of services after X is started be a more intuitive process.

You can also play around with the boot order and see what things you can delay until later in the boot process (maybe even after X starts?)

Note: Remember to leave/re-make the stop links in /etc/rc0.d, /etc/rc1.d and /etc/rc6.d for the halt, single user and reboot runlevels. See: man init

Background:

Being an ex-RH-user, I had at one time been frustrated and annoyed with update-rc.d for its requirement of having at least one symlink to keep it from rebuilding the links on the next upgrade and its (in my eyes) kludgy feel compared to chkconfig.

I wanted invoke-rc.d service start||stop ability for those infrequently used services, but I didn't want them running by default and I didn't want to uninstall them just to re-install the next time I wanted to use the services. (Uninstalling or deleting the init.d script was suggested to me on debian-user).

I also had a little bit of an adjustment at the use of only one run level instead of many as in RH (2=multi no network, 3=multi w network, 5=multi w X-windows).

The above solution is my way of combining the two quirks into a solution that seems to work for me. -- JacobAnawalt

Interactive Boot Editor (sysv-rc-conf)

The program sysv-rc-conf can be used to change which programs start at which runlevels, and makes speeding up your boot process simple and easy. Just be sure to check the man page for something before removing it if you are unsure what it does.

aptitude install sysv-rc-conf

Analyzing the boot process

Analyse the boot process and where time is spent using [http://www.bootchart.org/ Bootchart]. -- JeromeWarnier --

aptitude install bootchart bootchart-view