Section 6.1. It Takes Too Long to Boot

6.1. It Takes Too Long to Boot

Current versions of Windows boot fairly quickly, faster than most Linux configurations. But the reason Linux is slower to boot is that most distributions install, by default, a lot of software that few users needand to make things worse, the distributions are configured to have them start automatically. If you can get rid of this software, you have a win all around: the system boots faster, demands less of your hardware, and is more secure.

Many users don't know, for instance, that they are running a sendmail or Postfix mail daemon all the time. (One system I tried takes more than a minute just to get the sendmail daemon started.) For all except a handful of servers in a larger network that really deliver mail, running such a daemon is a waste of time and perhaps a security risk.

Several distributions (notably SUSE and Red Hat/Fedora Linux) hide the startup messages associated with the Linux kernel and Linux services when their systems boot. Many feel that hiding these messages (as is done during the Microsoft boot process) is less intimidating to novice users. But as a Linux expert, you need to know what's happening during the boot process. In this section, I'll show you how to find out what's running, decide what you need, and shut down the rest.

There are two approaches to this annoyance: uninstall services that you'll never need, and deactivate services that you aren't currently using. Both approaches are straightforward and should be familiar to most Linux geeks. Once you complete this process, you've reduced the time required to boot and improved the security of your systems.

6.1.1. Uninstalling Services

The commands for uninstalling a service are straightforward; the dpkg -r packagename or rpm -e packagename command removes the specified package from the system. But that leaves support packages and libraries on the system that you don't need. You can use command-line or GUI tools to uninstall them.

If you're annoyed by dependencies, read the related annoyances in Chapter 8.

6.1.1.1. Uninstalling at the command line

If you don't share directories and printers with Microsoft Windows computers, you don't need Samba on your Linux computers. In this case, you can uninstall Samba. However, if you want to disable all connections to Microsoft Windows computers, you'll also need to uninstall related packages such as samba-common.

You can uninstall Samba packages from the command line. First, you need to know what to uninstall. To find Samba-related packages on Red Hat/Fedora or SUSE, just run:

 r -qa | grep samba 

Alternatively, to find Samba-related packages on a Debian-based distribution, run:

 dpkg -l | grep samba 

Either command provides a list of installed packages associated with Samba, which you need to uninstall to remove Samba from your system.

When you manage packages from the command line, Debian goes one better. The apt series of commands allows the Linux geek to clean packages and associated dependencies. For example, the following command deletes not only the samba package but also the SWAT configuration package that accompanies it:

 apt-get remove samba 

If you've installed the yum (Yellowdog Updater, Modified) package management tool, you can remove all related packages with a similar command:

 yum remove samba 

But among the major distributions analyzed in this book, yum is installed by default only for Fedora Core. For more information, see "Avoid Dependency Hell with apt" and "Avoid Dependency Hell with yum" in Chapter 8.

6.1.1.2. Uninstalling with a GUI tool

Most systems have several hundred packages installed. If that's bewildering, a visual overview of related packages can help. The GUI tools from Debian, Red Hat, and SUSE organize packages in groups. With the embedded comments, these tools can help you review the purpose of each package.

GUI tools can help define, review, and uninstall packages by groups, which makes it less likely that you'll leave an orphaned package. Unfortunately, just about every distribution uses a different GUI tool: Debian offers Synaptic, SUSE offers YaST2, and Red Hat-based distributions offer the Package Management tool, also known as system-config-packages (Red Hat is moving toward pirut, at least on Fedora Core, as it integrates well with yum.) One advantage of the Red Hat, SUSE, and Debian GUI package-management tools is that they highlight any dependencies associated with packages you might want to uninstall. Thus, when you remove a tool, you can also remove these dependencies (libraries or other related software), assuming that they're not required for other packages you want to keep. Unfortunately, this is not foolproof. The GUI tools may not be able to identify dependencies if you've installed packages not built for your distribution.

Both command-line and GUI tools are effective in managing installed packages. Whether you use the command line or the GUI is a matter of personal taste.

6.1.1.3. Simplifying your system

On a Red Hat Enterprise Linux 3 computer I administer, I've uninstalled the mail, web, and DNS server package groups because I don't normally run those servers. This cleanup alone reduced the boot time for this computer by two minutes.

6.1.1.4. Uninstalling services built from a tarball

As a Linux geek, you've probably installed packages from a tarball. This is commonly associated with a package organized and compressed into a single file archive. Common tarball formats include .tar.gz, .tgz, and tar.bz2. All can be unpacked with the tar command; the -z and -j switches apply the gunzip and bunzip2 commands to these compressed formats.

When you unpack a tarball, the packaged files are opened in a subdirectory that is easy enough to clean up. But when you compile the files and install the software, the installation process often distributes the files to a number of different directories. Cleaning up these files is generally more trouble than it's worth. That's one reason the RPM and DEB package-management systems are preferred.

Package Database and Tarballs

If you want your package database to include everything that you've installed, you should create an RPM or DEB package from any tarballs that you want to use. Then when you install the package, it becomes a part of your installation database. If you later choose to uninstall that package, you'll know that you've removed all associated files. You may not have full functionality, however, as the package may not list all dependencies for your distribution.

I don't describe the package creation process in detail, as the process is long, and it is not an annoyance, per se. Section 6 of the RPM HOWTO (www.rpm.org/RPM-HOWTO/build.html) describes how you can create an RPM .spec file, which you can then use to create an RPM binary from a tarball of source code. Alternatively, the Debian New Maintainers' Guide (http://www.debian.org/doc/manuals/maint-guide/) can help you to create a DEB package from source code.

If you already have a package associated with another system, you may be able to convert between formats with the alien command.

6.1.2. Disabling Services

Generally, it's best to just remove any services that you don't need. Once you uninstall a service, you almost eliminate the risk that a cracker will use that service to break into your system.

However, if you're starting to configure a service such as vsFTP, you may want the service installed during the test process. In that case, you should disable that service to make sure it is not currently running and doesn't start up automatically the next time you boot Linux.

We've described how you can remove packages associated with a service. But if you want to deactivate a service, the process is a bit more complex.

First, list installed regular services. In Red Hat/Fedora, Debian, and SUSE, you can do so with the following command:

 ls /etc/init.d 

There are also other services associated with the so-called Internet "super server." By default on Red Hat/Fedora and SUSE, the super server is xinetd, which controls services in the /etc/xinetd.d directory, and individual scripts can be listed with:

 ls /etc/xinetd.d 

In Debian Linux, super-server services are configured directly in the /etc/inetd.conf configuration file. The way you deactivate a service varies between the Red Hat/Fedora/SUSE and Debian distributions.

With Red Hat/Fedora and SUSE, the simplest solution is to turn off the noted service. For example, if you're in the process of configuring Samba, you want to keep the packages installed, but you want to keep the daemons inactive. The following commands deactivate the Samba daemon and make sure that it doesn't start the next time you boot Linux:

 /etc/init.d/smb stop chkconfig smb off 

Once you've configured Samba, you'll want to make sure it starts in appropriate runlevels. The following command makes sure Samba starts in at least runlevels 3 and 5 in Red Hat/Fedora and SUSE Linux:

 chkconfig smb on 

Red Hat/Fedora and SUSE use the same defaults for text console (3) and GUI login (5) runlevels.

Managing scripts in Debian distributions is similar. In these cases, it's easiest to turn a service off in all runlevels. The following command deactivates Samba and then makes sure it does not start the next time you boot Linux:

 update-rc.d -f samba remove 

You can then restore Samba service in the runlevels of your choice. The following command restores it in the standard runlevels:

 update-rc.d -f samba start 20 2 3 4 5 . 

The 20 in the above command determines the order in which services are started and stopped in each runlevel. Lower numbers are run first. For example, my Debian /etc/rc2.d directory starts the S15bind9 service before S21sendmail, as sendmail may depend on DNS.

Debian handles runlevels differently from Red Hat/Fedora or SUSE. If you've installed a GUI for Debian, it automatically boots into the GUI login screen, unless you choose to boot into single-user mode. Unlike Red Hat/Fedora and SUSE, Debian runlevels 2 through 5 normally start and stop the very same services.

Major distributions provide GUI tools for managing runlevels and services. Like the package-management GUI tools described earlier in this chapter, the tools vary by distribution: Debian can use ksysv, Red Hat provides the Service Configuration tool, and SUSE embeds its runlevel editor in YaST. Unlike the package-management tools, the tools for managing services are usually considered eye candy and not as convenient for system administrations as doing things by hand on the command line, but you are free to try them and see whether they do the trick for you.

As most Linux tools are licensed under the GPL, you may find tools developed for a different distribution on your system.

6.1.3. 4G/4G Kernel Issue

Developers are adapting the Linux kernel for larger amounts of RAM. Traditionally, a 32-bit address space (4 GB) has been divided so that user-space applications have access to 3 GB and the kernel has access to 1 GB of memory. The so-called 4G/4G patch is designed so that both the kernel and user space can make full use of more than 4 GB of RAM on 32-bit systems.

The developers believe that this patch is not worth the overhead for 32-bit systems with less than 16 GB of RAM (http://lwn.net/Articles/39283/). I agree. I've found that the 4G/4G kernel slows down the boot process significantly on my systems (all with 1 GB of RAM or less). I therefore use Linux kernels without this feature and suggest that you do not install this patch unless you have appropriate levels of RAM.

6.1.4. Network Mounts

One more problem that can slow the boot process is a remotely mounted network directory. Certainly, remote mounts are valuable in many LANs; it is common practice to mount critical directorieseven the users' home directoriesfrom a central server. However, if you have connectivity problems on your network or if the server is prone to going down (hint: replace your Windows server with Linux), the systems mounting the directories can experience slow boots or even complete system hangs during the boot process.

The problem is most significant with shared NFS directories. If a server or network is down, Linux keeps trying to mount a remote NFS directory. If you've configured a hard mount, connectivity problems can stop your boot process for minutesor even, in some cases, stop it cold. In contrast, while NFS soft mounts are slower under optimal conditions, they expire by default after 60 seconds. If you have network problems, a NFS soft mount won't stop your boot process. However, soft mounts can lead to data corruption on some programs.

For a description of hard- and soft-mounted NFS directories, see the NFS HOWTO at http://nfs.sourceforge.net/nfs-howto/client.html.