Daemons

A daemon is a background process that performs a specific function or system task. In keeping with the
UNIX and Linux philosophy of modularity, daemons are programs rather than parts of the kernel. Many
daemons start at boot time and continue to run as long as the system is up. Other daemons are started
when needed and run only as long as they are useful.

The words “daemon” and “demon” both come from the same root, but “daemon” is an older form and
its meaning is somewhat different. A daemon is an attendant spirit that influences one’s character or
personality. Daemons are not minions of evil or good; they’re creatures of independent thought and will.
Daemons made their way from CTSS to Multics to UNIX to Linux, where they are so popular that they
need a superdaemon (xinetd or inetd) to manage them.

Before inetd was written, all daemons started at boot time and ran continuously (or more accurately,
they blocked waiting for work to do). Over time, more and more daemons were added to the system.
The daemon population became so large that it began to cause performance problems. In response, the
Berkeley gurus developed inetd, a daemon that starts other daemons as they are needed. inetd
successfully popularized this super daemon model, which remains a common way to minimize the
number of processes running on a server. Most versions of UNIX and Linux now use a combination of
inetd and always-running daemons.

INIT: THE PRIMORDIAL PROCESS

init is the first process to run after the system boots, and in many ways it is the most important daemon .
It always has a PID of 1 and is an ancestor of all user processes and all but a few system processes . At
startup, init either places the system in single-user mode or begins to execute the scripts needed to
bring the system to multiuser mode. When you boot the system into single-user mode, init runs the
startup scripts after you terminate the single user shell by typing exit or <Control-D>.

In multiuser mode, init is responsible for making sure that processes are available to handle logins on
every login-enabled device. Logins on serial ports are generally handled by some variant of getty (e.g.,
agetty, mgetty, or mingetty; see page 857 for details). init also supervises a graphical login procedure
that allows users to log directly in to X Windows. In addition to its login management duties, init also
has the responsibility to exorcise undead zombie processes that would otherwise accumulate on the
system.

init defines several “run levels” that determine what set of system resources should be enabled. There
are seven levels, numbered 0 to 6. The name “s” is recognized as a synonym for level 1 (single-user
mode). The characteristics of each run level are defined in the /etc/inittab file. init usually reads its initial
run level from the /etc/inittab file, but the run level can also be passed in as an argument from the boot
loader.

Possible Run Levels

0 : All processes are terminated and the machine comes to an orderly halt.
1, s, S : This represents single−user mode, which is most frequently used for system maintenance
and in situations where it may be preferable to have few processes running and no services activated

2 : Multiuser mode. Multiple user logins are allowed, all configured file systems are mounted

3, 4 : Multiuser mode with network services

5 : Multiuser mode with network services and X. This run level starts the X server and presents a
graphical login window, visually resembling any of the more expensive UNIX−based workstations.

6 : All processes are terminated and the machine is gracefully rebooted.

CRON AND ATD: SCHEDULE COMMANDS

Crond service is the Periodic Command Scheduler. It executes scheduled commands according to the
/etc/crontab file. It is one of an essential part of Linux systems. The cron daemon (known as crond on
Red Hat) is responsible for running commands at preset times. It accepts schedule files (“crontabs”)
from both users and administrators. cron is frequently employed for administrative purposes, including
management of log files and daily cleanup of the filesystem.

Cron should be started from /etc/rc or /etc/rc.local. It will return immediately, so you don't need to start
it with '&'. The -n option changes this default behavior causing it to run in the foreground. This can be
useful when starting it out of init.

Cron searches /var/spool/cron for crontab files which are named after accounts in /etc/passwd;
crontabs found are loaded into memory. Cron also searches for /etc/crontab and the files in the
/etc/cron.d directory, which are in a different format (see crontab(5)). Cron then wakes up every
minute, examining all stored crontabs, checking each command to see if it should be run in the current
minute. When executing commands, any output is mailed to the owner of the crontab (or to the user
named in the MAILTO environment variable in the crontab, if such exists).

Additionally, cron checks each minute to see if its spool directory's modtime (or the modtime on
/etc/crontab) has changed, and if it has, cron will then examine the modtime on all crontabs and reload
those which have changed. Thus cron need not be restarted whenever a crontab file is modified.

The atd daemon is a Periodic Command Scheduler. It run commands scheduled by the 'at' program at
their scheduled times. Most versions of Linux also include the anacron scheduler, which executes jobs at
time intervals rather than at specific times. anacron is particularly useful on systems that are not always
turned on, such as laptops.

The at command schedules a command to be run once at a particular time. This can be any command
that you normally have permission to run; anything from a simple reminder message, to a complex
script. You start by running the at command at the command line, passing it the scheduled time as the
option. It then places you at a special prompt, where you can type in the command (or series of
commands) to be run at the scheduled time. When you're done, press Control-D on a new line, and your
command will be placed in the queue.

XINETD AND INETD: MANAGE DAEMONS

xinetd and inetd are daemons that manage other daemons. They start up their client daemons when
there is work for them to do and allow the clients to die gracefully once their tasks have been
completed. The traditional version of inetd comes to us from the UNIX world, but most Linux
distributions have migrated to Panos Tsirigotis’s xinetd, a souped-up alternative that incorporates
security features similar to those formerly achieved through the use of tcpd, the “TCP wrappers”
package. xinetd also provides better protection against denial of service attacks, better log management
features, and a more flexible configuration language.

Among our example distributions, only Debian and Ubuntu use the standard inetd; RHEL, Fedora, and
SUSE all default to xinetd. xinetd and inetd only work with daemons that provide services over the
network. To find out when someone is trying to access one of their clients, xinetd and inetd attach
themselves to the network ports that would normally be managed by the quiescent daemons. When a
connection occurs, xinetd/inetd starts up the appropriate daemon and connects its standard I/O
channels to the network port.

The services file

The /etc/services file is a plain ASCII file providing a mapping between friendly textual names for
internet services, and their underlying assigned port numbers and protocol types. Every networking
program should look into this file to get the port number (and protocol) for its service.

Whilst the IP address provides the connection to the correct machine, it cannot distinguish the different
service that is required. The port is used to distinguish the application. It is a value from 0 to 65535. The
combination of IP address, port and protocol is called a socket, and has to be unique for every service.
The port numbers area available for both TCP and UDP, and when referred to in conjunction with the IP
address it specifies the "socket".

The first 1000 ports are reserved for specific applications, and on Linux can normally own be used by a
daemon / application that has super user privileges. These are referred to as well known ports.

Details of the reserved ports are listed on most systems in the /etc/services file

An entry is made up like this:

service port/protocol [aliases]
where:
service-name : is the friendly name the service is known by and looked up under. It is
case sensitive. Often, the client program is named after the service-name.
port : is the port number (in decimal) to use for this service.
Protocol : is the type of protocol to be used. This field should match an entry in the
protocols(5) file. Typical values include tcp and udp.
Aliases : is an optional space or tab separated list of other names for this service
Again, the names are case sensitive.

For example, when you type the command

$ telnet anchor smtp

telnet looks up the port number for the smtp service in the services file. Most systems ship with all the
common services already configured; you need only edit the services file if you add something new.The
services file is used only for bona fide TCP/IP services; similar information forRPC services is stored in
/etc/rpc.

Here are some selected lines from a services file (the original is ~570 lines long):

20 FTP -- Data

21 FTP -- Control

22 SSH Remote Login Protocol

23 Telnet

25 Simple Mail Transfer Protocol (SMTP)

53 Domain Name System (DNS)

80 HTTP

KERNEL DAEMONS

For architectural reasons, a few parts of the Linux kernel are managed as if they were user processes. On
older kernels, these processes could be identified by their low PIDs and names that start with k, such as
kupdate, kswapd, keventd, and kapm. The naming is less consistent under the 2.6 kernels, but ps
always shows the names of kernel threads in square brackets. For the most part, these processes deal
with various aspects of I/O, memory management,and synchronization of the disk cache. They cannot be
manipulated by the system administrator and should be left alone.

PRINTING DAEMONS

Several printing systems are in common use, and each has its own family of commands and daemons
that provide printing-related services. In some cases the families have been hybridized; in others cases,
multiple variants run on a single system.

eg. cupsd, lpd

FILE SERVICE DAEMONS

The following daemons are part of the NFS or Samba file sharing systems.

eg. rpc.nfsd, rpc.mountd, amd and automount

ADMINISTRATIVE DATABASE DAEMONS

Several daemons are associated with Sun’s NIS administrative database system such as ypbind, ypserv,
rpc.ypxfrd, lwresd etc.

ELECTRONIC MAIL DAEMONS

In addition to the core sendmail and Postfix mail delivery systems, which are bothin widespread use,
several daemons facilitate remote access to mailboxes.

eg. sendmail, smtpd, popd, imapd

REMOTE LOGIN AND COMMAND EXECUTION DAEMONS

The ability to log in and execute commands over the net was one of the earliest motivationsfor the
development of UNIX networking, and this facility is still a breadand-butter component of system
administration today.

eg. sshd, in.rlogind, in.telnetd, in.rshd

BOOTING AND CONFIGURATION DAEMONS

Most manageable network hubs and networkprinters boot by using some combination of the services
such as dhcpd, in.tftpd, rpc.bootparamd

OTHER NETWORK DAEMONS

The following daemons all use Internet protocols to handle requests. However,many of these “Internet”
daemons actually spend the majority of their time servicinglocal requests.

eg. talkd, ftpd, rsyncd, routed, gated, named, syslogd, in.fingerd, httpd

sshd: secure remote login server

Secure Shell (SSH) is a cryptographic network protocol for secure data communication, remote
command-line login, remote command execution, and other secure network services between two
networked computers that connects, via a secure channel over an insecure network, a server and a
client. The best-known application of the protocol is for access to shell accounts on Unix-like operating
systems, but it can also be used in a similar fashion for accounts on Windows. The encryption used by
SSH is intended to provide confidentiality and integrity of data over an unsecured network.

sshd (SSH Daemon) is the daemon program for SSH. It provides secure encrypted communications
between two untrusted hosts over an insecure network. The programs are intended to be as easy to
install and use as possible. sshd is the daemon that listens for connections from clients. It is normally
started at boot from /etc/rc. It forks a new daemon for each incoming connection. The forked daemons
handle key exchange, encryption, authentication, command execution, and data exchange.

named: DNS server

named is the most popular server for the Domain Name System. It maps hostnames into network
addresses and performs many other feats and tricks, all using a distributed database maintained by
named everywhere. When invoked without arguments, named will read the default configuration
file /etc/named.conf, read any initial data, and listen for queries.

To configure the DNS server, you need to set up a number of (text) database files. The DNS server
daemon (called named) first consults a boot file. This boot file tells the daemon to consult a series of
further database files which gives it enough information to start serving names.
httpd: World Wide Web server
httpd lets your site become a web server. httpd can send text, pictures, and sound to its clients. httpd is
the Apache HyperText Transfer Protocol (HTTP) server program. It is designed to be run as a standalone
daemon process. When used like this it will create a pool of child processes or threads to handle
requests.

On the Web, each server has an HTTPD or Hypertext Transfer Protocol daemon that waits in attendance for
requests to come in from the rest of the Web. A daemon is a program that is "an attendant power or
spirit" (Webster's). It sits waiting for requests to come in and then forwards them to other processes as
appropriate.