[Nemeth00] Chapter 28. Daemons

28. Daemons

AlthoughUNIX provides a versatile and generic multitasking environment, thekernel itself lacks the vivid personality and functionality that folkslook for when choosing an operating system to be their lifelongcompanion. Fortunately, UNIX systems come bundled with a rich set ofdaemons that provide much-needed vitality and flair. The systemadministrator can also add many additional daemons, whether downloaded,supplied by a vendor, or written by a user.
Adaemon is a background process that performs a specific function orsystem-related task. In keeping with the UNIX philosophy of modularity,daemons are programs rather than parts of the kernel. Many daemonsstart 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 areuseful.
“Daemon”was first used as a computer term by Mick Bailey, a British gentlemanwho was working on the CTSS programming staff at MIT during the early1960s.[1]Mick quoted the Oxford English Dictionary in support of both themeaning and the spelling of the word. The words “daemon” and “demon”both come from the same root, but “daemon” is an older form and itsmeaning is somewhat different. A daemon is an attendant spirit thatinfluences one’s character or personality. Daemons are not minions ofevil or good;they’re creatures of independent thought and will. Daemons made theirway from CTSS to Multics to UNIX, where they are so popular that theyneed a superdaemon (inetd) to manage them. - Daemon 术语的来源
This bit of history comes from Jerry Saltzer at MIT, via Dennis Ritchie.
Thischapter presents a brief overview of the most common UNIX daemons. Notall of the daemons listed here are supplied with all versions of UNIX,and not every daemon supplied with some version of UNIX is listed here.Besides making you more aware of how UNIX works, a knowledge of whatall the various daemons do will make you look really smart when one ofyour users asks, “What does xntpd do?”
Before inetdwas written, all daemons started at boot time and ran continuously (ormore accurately, they blocked waiting for work to do). Over time, moreand more daemons were added to the system. The daemon population becameso large that it began to cause performance problems. In response, theBerkeley 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.
Thereare many daemons that system administrators should be intimatelyfamiliar with, either because they require a lot of administration orbecause they play a large role in the day-to-day operation of thesystem. Some daemons that are described here in one or two lines havean entire chapter devoted to them elsewhere in this book. We providecross-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.
28.1. init: the primordial process
initis the first process to run after the system boots, and in many ways itis the most important daemon. It always has a PID of 1 and is anancestor of all user processes and all but a few system processes.
At startup, initeither places the system in single-user mode or spawns a shell to readthe system’s startup files. When you boot the system into single-usermode, 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, initperiodically issues complaints on the system console until the porteither becomes openable or is removed from the list of active ports.
Solaris is an exception to this behavior. See page109 for the sordid details.
SeeChapter 7 for more information about TTYs.
Onolder machines, the management of terminal ports was a mainstay ofsystem administration. These days, terminals are something of a relic.Most login sessions are established over the network through daemonssuch 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 page48.
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, initdefines several “run levels” that determine what set of systemresources should be enabled. There are usually seven or eight levels: 0to 6, plus “s” for single-user mode. The characteristics of each runlevel 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 page107 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 /etc/rcX.d. Bringing init to a new run level causes the appropriate scripts to be executed with the arguments start or stop.This facility allows startup and shutdown to be handled in an orderlymanner. A more detailed description of this mechanism is given startingon page25.

On FreeBSD systems, you can tell init to reread its control file by sending it a hangup signal (SIGHUP). Since init’s PID is always 1, you can simply run kill -HUP 1. Don’t forget the -HUP, or you will bring your system to a grinding halt.

Create Bookmark (Key: b)Create Bookmark
Create Note or Tag (Key: t)Create Note or Tag
Download (Key: d)Download
Email This Page (Key: e)Email This Page
PrintPrint
Html View (Key: h)Html View
Zoom Out (Key: -)Zoom Out
Zoom In (Key: +)Zoom In
Toggle to Full Screen (Key: f)
Previous (Key: p)Previous
Next (Key: n)Next
Related Content

Daemons
From: Linux® Administration Handbook, Second Edition
Daemons
From: IBM AIX 5L Reference for HP-UX System Administrators
OROUTED daemon
From: z/OS Version 1 Release 7 Implementation
Start options for daemons
From: ABCs of z/OS System Programming Volume 9
MANAGING DAEMONS
From: Linux Appliance Design, 1st Edition
Daemons
From: Linux® Desk Reference, Second Edition
Daemon Processes
From: Sun Certified System Administrator for Solaris™ 8 Study Guide
Network daemons
From: IBM eServer Certification Study Guide - AIX 5L Communications
Configuring the client daemon
From: Integrating AIX into Heterogeneous LDAP Environments
The error daemon
From: IBM eServer Certification Study Guide - AIX 5L Problem Determination Tools and Techniques