Chapter 12. Service Management

Table of Contents

Services at System Boot / Shutdown
Init Scripts
Gentoo Runlevels
List of Default Services
Service Configurations
General Service Configuration
Specific Service Configuration
Softlevel States
Bootlevel States


A service is a generic term which can be used in many contexts. Here, a service is a tool that runs in the background (also known as a daemon) which offers a certain functionality to the system or to the users. It is also possible that the tool just performs a single set of tasks and then quits.

Examples of services on a Linux system are:

  • the logger service, allowing programs on the system to send logging notifications to a global location which is then parsed and processed by a logger tool (example: syslog-ng).

  • the clock service, which sets the necessary environmental definitions (like time zone information)

  • the SSH service, allowing users to log on to your system remotely (through the secure shell)

  • ...

The scripts that manipulate the services are called init scripts (initialization scripts) and reside inside /etc/init.d. Although this is quite generic for all Linux distributions, Gentoo offers a somewhat different way of working with services, so not all activities mentioned in this chapter can be used for other distributions.

Services at System Boot / Shutdown

When your system boots, the Linux kernel starts a process called init. This tool executes a set of tasks defined by the various init levels on the system. Each init level defines a set of services to start (or stop) at this stage.

Within Gentoo, init levels are mapped onto named runlevels.

When init is launched, it will first run the sysinit and bootwait init levels. On Gentoo, the associated runlevels are also called sysinit and boot (sysinit is not configurable). Then, it will start the services for the runlevel it is configured to boot into (by default, init level 3). This init level at Gentoo is mapped onto the "default" runlevel.

For instance, the following services are launched when I start my laptop (sysinit not shown, but sysinit is always launched).

# rc-status boot
Runlevel: boot
 alsasound        [ started ]
 bootmisc         [ started ]
 checkfs          [ started ]
 checkroot        [ started ]
 clock            [ started ]
 consolefont      [ started ]
 hostname         [ started ]
 keymaps          [ started ]
 localmount       [ started ]
 modules          [ started ]
 net.lo           [ started ]
 rmnologin        [ started ]
 urandom          [ started ]
# rc-status default
Runlevel: default
 hald                 [ started  ]
 local                [ started  ]
 net.eth0             [ started  ]
 net.eth1             [ stopped  ]
 sshd                 [ started  ]
 syslog-ng            [ started  ]
 udev-postmount       [ started  ]
 xdm                  [ started  ]

As you can see, all configured services for the two runlevels (boot and default) are launched but one: net.eth1 isn't started (because it is my wireless interface and I'm currently on a cabled network which uses net.eth0).

The init configuration file is called /etc/inittab. The next excerpt is not a full inittab but explains most important settings:

id:3:initdefault:            # The default init level is 3
si::sysinit:/sbin/rc sysinit # sysinit       > run the Gentoo "sysinit" runlevel
rc::bootwait:/sbin/rc boot   # bootwait      > run the Gentoo "boot" runlevel
l0:0:wait:/sbin/rc shutdown  # init level 0  > run the Gentoo "shutdown" runlevel
l1:S1:wait:/sbin/rc single   # init level S1 > run the Gentoo "single" runlevel
l3:3:wait:/sbin/rc default   # init level 3  > run the Gentoo "default" runlevel
l6:6:wait:/sbin/rc reboot    # init level 6  > run the Gentoo "reboot" runlevel

Okay, so in the end, init uses Gentoo's runlevels. How do you configure those?

Init Scripts

An init script is a script that manipulates a particular service. It should support the "start" and "stop" arguments as these are used by the init tool (actually the rc tool which is called by init). For instance:

# /etc/init.d/udhcp start
# /etc/init.d/syslog-ng stop

As you can see, the scripts reside in the /etc/init.d directory. These scripts are usually provided by the tools themselves (udhcp and syslog-ng in our examples) but sometimes you might need to write one yourself. Luckily, this is less and less the case.

Next to directly executing the scripts, you can also use the rc-service tool:

# rc-service syslog-ng start

Gentoo Runlevels

Inside /etc/runlevels, Gentoo keeps track of the various scripts that need to be started when init starts a specific init level (which maps onto a Gentoo runlevel):

# ls /etc/runlevels
boot   default   nonetwork   single

Inside the directories you get an overview of the services that should be started when the runlevel is active. For instance, inside the default runlevel one could see:

# ls /etc/runlevels/default
local  net.eth0   net.wlan0   syslog-ng     xdm

The files found inside these directories are symbolic links, pointing to the associated init script found inside /etc/init.d:

# ls -l /etc/runlevels/default/local
lrwxrwxrwx 1 root root 17 Jul 12   2004 
  /etc/runlevels/default/local -> /etc/init.d/local

To manipulate the Gentoo runlevels, you can manipulate the symbolic links inside these directories directly, but you can also use the tools rc-update, rc-config and rc-status.

With rc-update, you can add or delete links from a particular runlevel. For instance, to remove the xdm init script from the default runlevel:

# rc-update del xdm default

With rc-status, you can see what scripts should be started in the selected runlevel and the current state. The next example shows that the net.eth0 runlevel is not started currently even though it is a service for the default runlevel (the reason is simple: I deactivated it as I don't need the interface currently):

# rc-status default
Runlevel: default
 local                                      [started]
 net.eth0                                   [stopped]
 net.wlan0                                  [started]
 syslog-ng                                  [started]
 xdm                                        [started]

With rc-config, you can manipulate the runlevels (just like with rc-update), show the current status of a particular runlevel (just like with rc-status) and view all currently available init scripts and the runlevels in which they are available (actually, rc-update can also do this using rc-update show):

# rc-config list

List of Default Services

When a pristine Gentoo install has finished, you will already have quite a few services available. The following sections give a quick overview of those services and what they stand for.


The alsasound service is responsible for loading the appropriate sound kernel modules (if they are known as modules) and saving/restoring the sound configuration at boot-up / shut down.

When the service is started, you might see kernel modules being loaded in memory. However, no other processes are started as part of this service.


The bootmisc service is responsible for various boot-level activities, such as:

  • loading the kernel parameters from /etc/sysctl.conf.

  • cleaning up directories to ensure they don't contain rogue information that might hinder the bootup

  • create, if they don't exist, system files with the correct permissions

Once the service has finished starting, no additional processes will be running.


The checkfs service is responsible for verifying the integrity of your systems' file systems. By default, it will verify the integrity of the file systems whose last digit in /etc/fstab isn't zero. You can force a root file system check by adding the forcefsck boot parameter or force a full file system check for all partitions (listed in the fstab file) by creating an empty "/forcefsck" file. This file will be automatically removed once the check has been finished.

# touch /forcefsck

On the other hand, if you want to ignore the file system checks, create the /fastboot file. It too will be automatically removed, this time when the system has booted.

Once the service has finished starting, no additional processes will be running.


The checkroot service is responsible for checking the consistency of the root file system. This service uses the same boot parameters (forcefsck or fastboot) as the checkfs service.

The service is also responsible for remounting the root file system read-write (by default it gets mounted read-only by the Linux kernel).

Once the service has finished starting, no additional processes will be running.


The clock service is responsible for setting the system time based on the BIOS clock and the settings defined in /etc/conf.d/clock. It will also synchronise the system clock with your hardware clock during shut down.

Once the service has finished starting, no additional processes will be running.


The consolefont service is responsible for setting the console font.

Once the service has finished starting, no additional processes will be running.

host name

The host name service is responsible for setting your systems' host name based on the input of /etc/conf.d/hostname.

Once the service has finished starting, no additional processes will be running.


The keymaps service is responsible for setting your keyboard mapping (qwerty, azerty, dvorak, ...) based on the /etc/conf.d/keymaps file.

Once the service has finished starting, no additional processes will be running.


The local service is responsible for handling the scripts defined in /etc/local.d. The scripts, with suffix .start or .stop, are executed in lexical order (of course during start or stop of the system, depending on the suffix).

The local service is started as the last service before you can log on to your system. It is also the first one to be stopped when the system is shutting down.

As you completely manage what this service does, I can't tell you what will happen when the service has finished starting. By default however, it doesn't do anything.


The localmount service is responsible for mounting all local file systems (mentioned in /etc/fstab). It also initiates the necessary support for USB file systems, specific binary format file systems, security file systems and enabling the swap file system.

Once the service has finished starting, no additional processes will be running.


The modules service is responsible for automatically loading the kernel modules listed in /etc/modules.autoload.

Once the service has finished starting, no additional processes will be running.

net.lo (net.*)

The net.lo service is responsible for loading networking support for a specific interface. Although the name suggests that it only supports the lo (loopback) interface, the service actually supports any interface. Other interface scripts are just symbolic links to this script.

Once the service has finished starting, no additional processes will be running.


The rmnologin service is responsible for changing the state of your system from a non-logon-capable system (set by the bootmisc service) to a logon-capable one. This is needed to ensure no-one can log on to your system while important services are being loaded.

Once the service has finished starting, no additional processes will be running.


The sshd service is responsible for launching the secure shell daemon, which allows you to access your system from a remote location (as long as the network / firewalls permit it) in a secure manner.

Once the service has finished starting, you will find the sshd process running.

syslog-ng (or any other system logger service)

The syslog-ng service is responsible for starting the syslog-ng daemon, which is responsible for watching the /dev/log socket for log events and managing those events by dispatching them towards the right log file (or other log server).

Once the service has finished starting, you will find the syslog-ng process running.


The udev-postmount service is responsible for re-evaluating udev events between the moment udev was started and the moment udev-postmount is started which might have failed for any reason (for instance because not everything was up and running yet).

Once the service has finished starting, no additional processes will be running.


The urandom service is responsible for initializing the random number generator in a somewhat more secure manner (using a random seed obtained during the last shut down of the system). Without this, the random number generator would be a bit more predictable.

Once the service has finished starting, no additional processes will be running.

Service Configurations

General Service Configuration

Gentoo's general configuration file for the start-up service behaviour is /etc/rc.conf.


Inside the rc.conf file, generic settings which are (or might be) needed by several services can be configured. The syntax is, as usual, "key=value". Since openrc (new init system for Gentoo), all settings are bundled in this file. Earlier systems spread the configuration across /etc/rc.conf and /etc/conf.d/rc. The latter is now deprecated.

The file is pretty well documented.

Specific Service Configuration

Each system service within Gentoo can be configured using a file in /etc/conf.d which is named the same as the service itself (except in a few specific cases like network configurations, which use the /etc/conf.d/net configuration file). All these files use a key=value syntax for configuration purposes.

For instance, the /etc/init.d/clock init script can be configured using the /etc/conf.d/clock configuration file.

Softlevel States

Gentoo supports softlevels, which are specific configurations of one or more services. The need exists, because you might create different runlevels (say "work" and "home" instead of just "default") in which services need to be configured differently. As the services would only use their general configuration file, this wouldn't work.

To initiate softlevels, you need to specify "softlevel=<yoursoftlevel>" at the kernel option line (for instance, in GRUB, this means you add it to grub.conf's kernel line). Once set, Gentoo will try to start the softlevel given instead of the default runlevel (coincidentally named "default") and first look for configurations of this softlevel for each service. If it cannot find specific configurations, it will use the default one.

An example use of softlevels would be to define a softlevel "work" and a softlevel "home". Both initiate different settings, such as different networking settings, different clock settings, different crypto-loop settings, etc. This could result in the following two GRUB configuration entries:

title=Gentoo Linux @Home
kernel /kernel-3.8.5 root=/dev/sda2 softlevel=home

title=Gentoo Linux @Work
kernel /kernel-3.8.5 root=/dev/sda2 softlevel=work

Whenever a service is started (or stopped), it will look for its configuration file called /etc/conf.d/<servicename>.<softlevel> (for instance, /etc/conf.d/ and if that doesn't exist, use the default one (for instance, /etc/conf.d/clock).

To finish the softlevel, create a new runlevel with the softlevels' name:

# mkdir /etc/runlevels/work

Finish up by adding the services you need to this runlevel.

Bootlevel States

The idea behind bootlevel is the same as softlevel, but instead of changing the default runlevel "default", you change the default boot runlevel "boot".