• Choose a category
• All
• Classic-Fiction

By Root 2859 0

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 is responsible for starting other daemons as they are needed. inetd was so successful that all major versions of UNIX now include it and most new daemons run under its control.

There are many daemons that system administrators should be intimately familiar with, either because they require a lot of administration or because they play a large role in the day-to-day operation of the system. Some daemons that are described here in one or two lines have an entire chapter devoted to them elsewhere in this book. We provide cross-references where appropriate.

We start this chapter by introducing a couple of very important system daemons (init and cron) and then move on to a discussion of inetd. Finally, we briefly describe most of the daemons a system administrator is likely to wrestle with on our four example systems.

1. This bit of history comes from Jerry Saltzer at MIT, via Dennis Ritchie.

28.1 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 spawns a shell to read the system’s startup files. When you boot the system into single-user mode, init reads the startup files after you terminate the single-user shell, usually by typing exit or .

After processing the startup files, init consults a configuration file (/etc/inittab on most systems, /etc/ttys on FreeBSD) to determine on which physical ports it should expect users to log in. It opens these ports and spawns a getty process on each one.2 If a port cannot be opened, init periodically issues complaints on the system console until the port either becomes openable or is removed from the list of active ports.

See Chapter 7 for more information about TTYs.

On older machines, the management of terminal ports was a mainstay of system administration. These days, terminals are something of a relic. Most login sessions are established over the network through daemons such as rlogind, telnetd, and sshd (discussed later in this chapter).

In addition to its terminal management duties, init also has the ghoulish task of exorcising undead zombie processes that would otherwise accumulate on the system. init’s role in this process is described on page 48.

You can shut down the system by sending init a signal—usually SIGTERM—that makes it take the system to single-user mode. This is the last step in most shutdown scripts. init is so essential to the operation of the system that the system will automatically reboot if init ever dies.

On most modern systems, init defines several “run levels” that determine what set of system resources should be enabled. There are usually seven or eight levels: 0 to 6, plus “s” for single-user mode. The characteristics of each run level are defined in the /etc/inittab file.

init is usually passed its initial run level as an argument from the boot loader. If “s” is specified, init enters single-user mode. Otherwise, it scans /etc/inittab for entries that apply to the requested run level and executes their corresponding commands.

See page 107 for more information about the inittab file.

The telinit command changes init’s run level once the system is up. For example, telinit 4 forces init to go to run level 4. telinit’s most useful argument is -q, which causes init to reread the /etc/inittab file.

Many systems implement an additional layer of abstraction on top of the basic run level mechanism provided by init. These systems keep startup scripts in the directory /etc/init.d, from where they are linked into run-level-specific directories called