Table of Contents
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.
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?
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 startInside /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 singleInside 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 xdmThe 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/localTo 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 defaultWith 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
(...)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:
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 /forcefsckOn 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.
The hald service is responsible for starting the hardware abstraction layer daemon (see HAL).
Once the service has finished starting, you will find the hald process running as the haldaemon user.
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.
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.
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.
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.
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.
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-2.6.31 root=/dev/sda2 softlevel=home title=Gentoo Linux @Work kernel /kernel-2.6.31 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/clock.work) 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/workFinish up by adding the services you need to this runlevel.