|
|
| Previous | Table of Contents | Next |
A number of system daemons can exist in a Unix system. Some are only found in a specific version of Unix, but many daemons are common to all versions of Unix. This section discusses many of the common daemons and describes their function on the system.
The init daemon is known as the parent process for all the processes on the system. It performs a broad range of functions that are vital to the operation of a Unix system.
The most commonly known purpose of the init process is to boot the system. The method init uses to boot the system differs among Unix versions. The BSD and XENIX init programs, for example, do not work the same way as the System V implementation. The System V init program relies on the file /etc/inittab to provide details of how init is to govern the startup and initialization of the various services on the system. The init process is commonly known as “init” because of its role in the initialization of various processes during system operation.
The init program considers the system to be in a run level at any given time. Run levels are the operating states of the system. For the purposes of this section, a run level can be viewed as a software configuration; each configuration allows only a selected group of processes to exist.
Some Unix system administrators refer to swapper as a daemon, and others do not. The swapper process is responsible for scheduling the use of memory by the various processes on the system. The swapper process is actually part of the kernel, so you could say that it is not a daemon after all.
update and bdflush are similar commands that periodically execute the sync system call to flush disk buffers. These daemons execute every 30 seconds. Users and system administrators rely on these daemons to update the file system in case of a crash. Although two commands are listed, your system will see one or the other, but rarely both.
The lpd daemon is part of the BSD print services. It listens for and accepts connections via TCP/IP to submit a print request. The lpd daemon relies on the LPD protocol to accept the job, and submit it to the requested printer. This daemon was almost exclusively found on BSD-based systems until the more popular System V derivatives started adding similar services.
Note: Some System V implementations have an lpd daemon but still require the use of the System V print spooler for the job to be printed.
The lpsched daemon is the System V version of the print spooler. It performs the same tasks as the BSD lpd program, but in a much different format. Despite lpsched’s inability to communicate directly via the LPD protocol, it is still considered stronger than lpd because of its flexibility with printer interface scripts.
Note: Some lpsched implementations, such as found on Solaris 2.x, are capable of receiving LPD requests.
The cpd and sco_cpd daemons are the license managers for SCO products. They are similar to license managers on other implementations of Unix in that they ensure that all products on the local network have unique serial numbers. With the release of SCO OpenServer 5.0, the license managers support shrink-wrapped software and operating system software.
The cron daemon is the automated task scheduler; it runs scheduled jobs at the requested time. A user may want to execute a number of jobs at regular intervals, for example. To do this, a crontab file is created resembling the following:
0,15,30,45 * * * * /usr/stats/bin/getstats border1.ottawa 0 3 * * 0 /usr/stats/bin/merge border1.ottawa 0 4 * * 0 /usr/stats/bin/ar border1.ottawa
This specification identifies when the job is to be executed and what the command to be executed is. The cron daemon builds an internal list of the jobs to be executed, and runs them at the requested time intervals.
The syslog daemon is a UDP/IP service that allows information and status messages for different network services to be logged through a central logging mechanism. The syslog daemon is controlled through the file /etc/syslog.conf and can write messages of different types into different log files. A sample syslog.conf file is shown here:
user.* /usr/log/user_logs kern.* /usr/log/kernel_logs daemon.* /usr/log/messages mail.debug /usr/log/mail lpr.debug /usr/log/mail cron.debug /usr/log/cron news.debug /7usr/log/news auth.* /usr/log/authenticate local3.debug /usr/log/wrapper local7.debug /usr/log/backbone *.critical /usr/log/critical *.emerg *
Note: Although you may have more than 16 entries in your syslog configuration file, many implementations of syslog can only open a maximum of 16 log files.
The syslog.conf file lists the facility priority level of the message, and where that message is to be stored when received. Any message that is received with a priority level of critical, for example, is written to the file /usr/log/critical.
syslogd reads and forwards system messages to the appropriate log files, to users, or to both, depending on the priority of a message and the system facility from which it originates. The following output lists sample syslog entries that show different types of information captured by syslogd.
Aug 26 05:21:37 nms in.tftpd[14037]: connect from C7-1.vcr.home.org Aug 26 09:47:03 nms sendmail[14344]: AA14344: message-id= <9508261345.AA14344@nms.home.org> Aug 26 09:47:03 nms sendmail[14344]: AA14344: from=stats, size=149, class=0 Aug 26 09:47:05 nms sendmail[14347]: AA14344: to=stats@home.org, delay=00:01:32, stat=Sent Aug 26 11:00:01 nms cron: > CMD: 14426 c /usr/stats/bin/getstats border1. .montreal Aug 26 11:00:01 nms cron: > stats 14426 c Sat Aug 26 11:00:01 1995 Aug 26 11:00:01 nms cron: < noc 14421 c Sat Aug 26 11:00:01 1995 Exit status 1 Aug 26 11:00:53 nms cron: < stats 14422 c Sat Aug 26 11:00:53 1995 Aug 26 11:01:39 nms cron: < stats 14423 c Sat Aug 26 11:01:39 1995 Aug 26 11:02:02 nms cron: < stats 14426 c Sat Aug 26 11:02:02 1995 Aug 26 11:04:33 nms cron: < stats 14425 c Sat Aug 26 11:04:33 1995
The sample log entries also show you what information is saved by syslog: a time stamp, the name of the machine where the message originated, the command and PID, and the message.
Note: Manual syslog entries can be made using the logger command, discussed later in this chapter.
| Previous | Table of Contents | Next |