Disabling unused daemons to speed up your boot sequence

Many Linux distros usually start a lot of daemons when booting, resulting in a long wait before you can get to work after powering on your machine. Some of those daemons are rarely used (or even not al all) by the majority of users. This tutorial describes how to disable unused or rarely used daemons in a proper way, resulting in faster boot sequences and less CPU load.Note: Although this tutorial aims to be system-friendly and not dangerous, please do not disable any service if you don't know what you are doing. Especially on server systems, (accidently) disabling an important service can have serious consequences. This tutorial is provided as-is, without any warranty and so on. Just be careful, ok? =)Another note: This tutorial uses the words "service" and "daemon". These words have an almost identical meaning, although service focuses a bit more on what a process does, or, in other words, which service a process provides. The word daemon refers to the "physical" (how could software ever be physical?) process.

First Part: The how-to (or howto)

Indeed, this tutorial is splitted in two parts to allow easy reading. The first part explains how to disable those services (and which services to disable) in a short and clear way. The second part (the tutorial part) explains what's behind it, and allows deeper insight in Linux booting. If you don't want and/or need that deeper insight, don't read the second part =).

Finding out what's running on your system

Most distros feature some kind of tool which allows you to manage the daemons that are started on your computer when booting. The most common one is chkconfig, which features a commandline interface. You can list all processes that are started when booting to graphical mode with the following command:

[rechosen@localhost ~]$ /sbin/chkconfig --list | grep "5:on"

When running a text-mode system, you will usually boot to runlevel 3. To see the processes that are started at boot time on these systems, use this command:

[rechosen@localhost ~]$ /sbin/chkconfig --list | grep "3:on"

Many distros also feature a GUI for daemon startup configuration. A well-known one is serviceconf. You will usually find such a GUI in areas like "System" or "Configuration", named like "Services" or "Boot configuration" or "Daemons" (note that the second one can also be a configuration GUI for the bootloader, like GRUB or lilo, which is not what we're dealing with right now). Using a GUI configurator is recommended, because they usually are more tuned for your distro than chkconfig.The following section contains a list of daemons that can be disabled in certain cases. Compare the list of daemons that are started on your system to the list below, read the descriptions and determine whether or not it would be a good idea to disable it. Once you made up your mind on which services you're going to disable, continue to Disabling Daemons.

Common unused / rarely used daemons

The following list contains daemons that may not be used by a 'normal' end-user. You can compare the list of daemons started up on your system to this list, and see if you could safely disable some of those daemons.

• Bluetooth
  • hcid, sdpd and hidd (These daemons provide Bluetooth services and are unnecessary if you don't have any Bluetooth hardware)
• Printing
  • cups and cups-config-daemon (These daemons provide printer services and are unnecessary if you don't have any printer hardware attached to your local pc or to a network pc)
  • hpiod and hpssd (These daemons provide extensive support for HP printers. They can safely be disabled if you never print using an HP printer)
• Console
  • gpm (This daemon provides mouse support for text-based applications, like Midnight Commander. It also provides copying/pasting with the middle mouse button in console environments. Can be disabled if you do not use the console much)
• Webserver
  • httpd (This daemon provides web hosting services, and is unecessary on workstations and servers that do not host any websites or webinterfaces)
  • mysqld and postgresqld (These daemons provide database backend services. You can usually disable them if you're not running a webserver, although some applications use these databases for their data storage)
• Firewall
  • netfilter/iptables (This daemon provides firewall services. Those are not that necessary if you're behind a router or smoothwall with a built-in firewall)
• InfraRed
  • irda (This daemon enables your computer to communicate with other devices using IR (InfraRed) hardware. If you haven't got such hardware, you can safely disable this service)
  • lircd (This daemon provides remote control support using IR (InfraRed) receivers. Can be disabled if you don't have hardware capable of receiving IR signals)
• Multiple CPU's
  • irqbalance (This daemon balances interrupts over multiple CPU's in the system. Can be disabled if you don't have multiple CPU's or a dual core processor)
• Software RAID
  • mdmonitor, mdadm and mdmpd (These daemons provide information about and management functionality over software RAID devices. They are unnecessary if you don't use software RAID)
• DNS Server
  • named (also known as BIND) (This daemon provides DNS server functionality. It is usually not needed on workstations)
• Remote kernel logging
  • netdump, netcrashdump and netconsole (These services provide functionality for kernel logging and debugging over network connections. Only necessary if you want to view your kernel's log and debugging messages on an other computer)
• Fileservers
  • NFS server
    • nfs (This daemon provides NFS server functionality, allowing other computers with NFS clients to connect to your computer and access files. You can disable this if you don't need/want others to access your system using NFS)
    • portmap (This daemon manages RPC connections, used by protocols like NFS and NIS. Only needed on computers that need to act as a server)
    • rpcsvcgssd (This daemon manages RPCSEC GSS contexts for the NFSv4 server and is not needed unless you are running an NFS server)
  • Samba server
    • smbd and nmbd (These daemons provides other computers (Windows computers, too) with access to your files. This is not needed if you don't want others to be able to access your files over the network)
• Network Authentication
  • nscd (This daemon handles passwd and group lookups and caches their results. Only needed when using a 'slow' name service, like NIS, NIS+, LDAP, or hesiod)
  • portmap (This daemon manages RPC connections, used by protocols like NFS and NIS. Only needed on computers that need to act as a server)
• Remote time setting
  • ntpd (This daemon sets your system time to a value it retrieves from a so-called ntp server, which usually serves a very accurate time. Although it is a useful feature, it tends to slow your system's startup a lot, especially if the server cannot be found)
• Process Accounting
  • psacct (also known as acct) (This daemon provides process accounting, which gives a more detailed insight into the execution of commands on your system. This is usually not needed unless you are running a server that is accessed by a lot of people that you cannot trust entirely)
• Plaintext Authentication Requests
  • saslauthd (This daemon handles SASL Plaintext Authentication Requests, and is only required on a server that needs to communicate using SASL mechanisms)
• Mailserver
  • sendmail (This daemon sends and forwards email messages, acting as a server. You don't need this daemon to be able to send a normal message. It is only needed if you need your computer to act as a mailserver)
  • spamd (also known as Spamassassin) (This daemon checks incoming mail messages for spam. This can usually be disabled, but keep in mind that some mail clients, like KMail, can use spamd's functionality)
• SSH Server
  • sshd (This daemon allows remote login to your computer using the SSH protocol. It can be disabled if you don't want/need this access)
• VNC Server
  • vncserver or xvnc (This daemon allows others to get a virtual graphical Desktop that actually runs on your computer)
• Task Scheduler
  • cron (and variants, like vixie-cron...) (This daemon runs periodic tasks on your system, like updating the search index or the manpage index, but also rotating logfiles. This one is generally required for a server system to run correctly, but workstations may be able to run without it)

Disabling daemons

When using a GUI to manage the daemons started at boot-time, you will usually be able to disable them by simply unchecking a checkbox. When using chkconfig, you can use the following syntax:

[rechosen@localhost ~]$ /sbin/chkconfig name off

Replace "name" with the name of the daemon you want to disable. If you accidently disabled a wrong daemon, you can turn it on again this way:

[rechosen@localhost ~]$ /sbin/chkconfig name reset

You might think this is illogical, that it should be:

[rechosen@localhost ~]$ /sbin/chkconfig name on

Well, it shouldn't. The above command would turn on the starting of the daemon for a fixed set of runlevels, no matter what the previous values were. That's not exactly what we want, as we want it to switch it back to the old state. The word "reset" tells chkconfig to restore the values specified in the init script that contains the instructions on how to start the daemon. These values are (or should be) the defaults. Remember that the default values are not always equal to the old values, but they will mostly be closer to them than the values that "on" implies. You might need to modify a select amount of runlevels to correct it. You can do this by specifying which runlevels should be altered, like this:

[rechosen@localhost ~]$ /sbin/chkconfig --level 35 name on

The above command would turn on the startup of the daemon "name" for the runlevels 3 and 5. The argument for "--level" is just a string of runlevel number, without separation. Another example:

[rechosen@localhost ~]$ /sbin/chkconfig --level 235 name on

Second part: The tutorial

This part will explain what's behind all the commands above. If you want to know how Linux "knows" what to start at boot time, what a "runlevel" is and why there usually are 7 of them (or, arguably, 8), read on.Note: This part will not be right for every distro. There are a lot of differences between distros at this point, so I tried to expose the most default configuration.

How Linux "knows" what to start at boot time

When you boot up a Linux computer, you'll usually see the bootloader (after the BIOS has done its part of the booting process). The bootloader, usually Lilo or GRUB, is configured to load the kernel of the Linux into the memory of your computer. The kernel then leaves the bootloader behind and continues booting on its own, initializing hardware and making itself ready to start running init. And init is the process we're looking for: it is the first process run, and it spawns all other processes. But where does init look to know which processes to start? The short answer is: in /etc/rc*.d/ (usually). But that's not the full answer. To understand how it uses the files in those directories, we will first need to understand what runlevels are.

Runlevels

A runlevel is the process state in which a system can reside. For example: runlevel 1 usually is the rescue mode, it boots the system starting as few processes as possible, providing the user with a root-access console, without networking functionality and without any GUI. On the other hand, runlevel 5 usually is the full-fledged graphical multi-user mode. There also are special runlevels that you shouldn't boot to, but that you could switch to after booting: for example, switching to runlevel 0 (zero) shuts down your computer (don't try this until you read the full tutorial) and switching to runlevel 6 will make your system reboot itself. Now for the full list of runlevels and their common configuration:

• 0: Shuts down the system (to be switched to after booting)
• 1: Boots the system to a rescue mode
• 2: Boots the system to a multi-user mode without networking functionality (some systems, like Debian, use this as a full-fledged mode)
• 3: Boots the system to a multi-user mode with networking functionality (some systems, like Debian, use this as a full-fledged mode)
• 4: Generally not used (sometimes it is the same as runlevel 5 or 3)
• 5: Boots the system to a full-fledged graphical multi-user mode (with networking, of course)
• 6: Reboots the system (to be switched to after booting)
• (s or S: Usually similar or equal to runlevel 1)

As the last runlevel is not always considered a real runlevel (it is then called an alias), the number of runlevels is usually seven, but arguably eight. You can switch between all runlevels after having booted, although 0 and 6 will (of course) require you to boot again before you can switch again. Switching between runlevels is usually done with the init command, like this:

[rechosen@localhost ~]$ init 3

The above command would (run as root or with root permissions) switch your system to runlevel 3, unless it's already running in runlevel 3 (replace the 3 with an other digit if you want to switch to an other runlevel). When switching between runlevels, init terminates the processes that were running in the old runlevel which should not run in the new one (these are zero processes when booting and all processes when shutting down or rebooting) and starts the processes that were not running in the old runlevel which should run in the new runlevel (these are zero processes when shutting down or rebooting, but when booting, it depends on the runlevel you're booting to). And now we can go on to the way init "knows" what to start and what to stop.

What to start and what to stop?

When the init process is started by the kernel, it first looks in the /etc/inittab file to see what to do in case of a certain runlevel. This file usually tells init to look in the corresponding /etc/rcX.d/ directory, where X is the runlevel. For example, when booting to runlevel 5, init will run the scripts in /etc/rc5.d/ (please note (again) that this does not apply to all distros). These "scripts" usually are symlinks to the corresponding service management scripts in /etc/init.d/ (or /etc/rc.d/init.d/). But how can such a script understand whether init wants it to start or stop the service? Well, when init wants the script to start the process, it will run the script with "start" as the first argument. When wanting the script to stop the service, init will pass "stop" as the first argument. You can also do this yourself if you want to start or stop a service. For example:

[rechosen@localhost ~]$ /etc/init.d/ntpd stop

The above example would stop the ntpd daemon. To start it again use the following command:

[rechosen@localhost ~]$ /etc/init.d/ntpd start

Stopping and starting can usually be combined in the following way.

[rechosen@localhost ~]$ /etc/init.d/ntpd restart

This is useful in case you want a daemon to re-read its config files. Depending on the service the script was written for (and the script itself), other arguments may also be supplied.Anyway, let's get back to the /etc/rcX.d/ directory. This directory is filled with files named like "K59somedaemon" and "S10anotherdaemon". I'll give a short explanation:

• "K" means "kill" and "S" means "start": The symlinks starting with "K" will be executed with a "stop" argument by init, and the symlinks starting with "S" will be executed with a "start" argument.
• The two digits after "K" or "S" don't mean anything really special, they are just used for sorting. Symlinks that need to be run before certain other ones should have a lower number than the other ones.
• The name of the daemon after it is actually not necessary for init, but it's good practice for sysadmins so they can instantly see what the symlink is for.

Finally, you should know that pretty much any distro has got some check somewhere to ensure that already running processes are not started again (which would result into two interferring processes, unless the daemon itself checks if there isn't an other instance running) and that already terminated processes will not be "reterminated". This is usually done by some special program or script that is called to do the actual starting.

Final words

Well, I hope this tutorial helped you cutting on the CPU load and boot time of your computer and understanding what makes a Linux system come up after you turned your computer on. If you have any suggestions (for example: another daemon that seems to be unnecessary in certain cases or another way to manage the startup of daemons) please leave a comment.