The dfmon Program

The program that you have read about to this point is shown in Listing 2.1 and Listing 2.2 at the end of the chapter. Listing 2.1 contains the entire Bourne shell source code for the daemon. It has been tested on numerous platforms including SunOS 4.1.3 and 4.1.4, SCO OpenServer 5.0, HP-UX 9.0, SCO Unix 3.2 Version 4.0, and BSDI Version 2.0.

This Bourne shell daemon sends little or no output to the standard input/output channels. With the exception of text that is printed during the startup of the program, the only other text generated is saved through the syslog service, or into a file directly.

Your dfmon program is added to the system startup scripts for the machine on which it will run. The script could be /etc/rc.local or /etc/rc2.d/S89dfmon. The exact location of the startup files differs from one Unix implementation to another.

The dfmon program starts by reading the configuration file that is defined in the shell script. This configuration file defines the operating environment for the script. The variables defined in the configuration file are shown in Listing 2.2. dfmon puts most of the system specific components of the program inside a shell function for each specific operating system. The majority of the differences among Unix implementations are in the df output, which is a direct problem for this script.

When the df output for the file system has been determined, it is examined and compared with the low and critical free space values from the configuration file. The available space is checked first against the value for the critical level. If the available space is less than the desired amount, the logger command is used to send a warning message to the syslog daemon, or a warning is sent to the system user using the wall command.

If the available disk space is greater than the critical level, then the low level is checked. If the value is less than the low level for the file system, the same procedure is followed.

The logger command provides the capability for non-compiled programs to send messages to the syslog daemon for logging and potential action. The command line looks like this:

/usr/bin/logger -t "dfmon" -p $SYSLOG_FAC.crit "CRITICAL Alarm: $FILESYS
  space: Free=$FREE"

This command line creates the following message in the system syslog file:

Aug 26 15:16:39 hp dfmon: CRITICAL Alarm: / space: Free=1093530

This program enables any system administrator to record important system events in the syslog. Remember though, that if the syslog daemon is not running when the logger command is executed, the information sent by the logger is ignored.

For systems that do not have syslog, or when the system administrator chooses not to use syslog, this daemon is capable of saving the information to a file and sending a warning message to users who are logged in using the wall command, as seen in this example:

Sun Aug 27 17:47:35 EDT 1995 Starting Disk Monitor Daemon ....

Broadcast Message from chrish (pty/ttys0) Sun Aug 27 17:47:35…
Sun Aug 27 17:47:35 EDT 1995 hp dfmon: CRITICAL Alarm: / space:
  Free=1093048

This section has shown you how to create a daemon using the Bourne/Korn shell language. Many system administrators, however, do not use the shells for this type of activity because it still relies on the services of other programs, which may not be available. For this reason, you also need to know how to create daemons using PERL.

Creating Daemons with PERL

The PERL programming language, a cross between the capabilities and syntax of the Bourne/Korn shell and the syntax and facilities of C, is a strong environment for building daemons. Like the earlier discussion, this section uses a practical example to help you follow the construction of a daemon in PERL. However, this is not meant as a tutorial for the PERL language. This section considers similar issues as the Bourne shell, but with the idiosyncrasies of the PERL language.

For administrators responsible for maintaining a Unix system, a large amount of concern is focused on the currently executing processes. This is especially true of processes that are started when the system is brought up that should never exit. No matter how hard you try to keep these processes running, sometimes it just isn’t possible. Several reasons include maximum parameters being reached, programming errors, or a system resource that isn’t available when needed.

One way of combating this situation, which may not work depending upon the process involved, is to use the /etc/inittab file on System V systems. The /etc/inittab file contains a list of processes that are to be executed when the system enters a run level. This file also contains information on what to do when the process exits. A sample /etc/inittab file is shown here:

ck:234:bootwait:/etc/asktimerc </dev/console >/dev/console 2>&1
ack:234:wait:/etc/authckrc </dev/console >/dev/console 2>&1
brc::bootwait:/etc/brc 1> /dev/console 2>&1
mt:23:bootwait:/etc/brc </dev/console >/dev/console 2>&1
is:S:initdefault:
r0:056:wait:/etc/rc0  1> /dev/console 2>&1 </dev/console
r1:1:wait:/etc/rc1  1> /dev/console 2>&1 </dev/console
r2:2:wait:/etc/rc2 1> /dev/console 2>&1 </dev/console
r3:3:wait:/etc/rc3  1> /dev/console 2>&1 </dev/console
sd:0:wait:/etc/uadmin 2 0 >/dev/console 2>&1 </dev/console
fw:5:wait:/etc/uadmin 2 2 >/dev/console 2>&1 </dev/console
rb:6:wait:/etc/uadmin 2 1 >/dev/console 2>&1 </dev/console
co:2345:respawn:/etc/getty tty01 sc_m
co1:1:respawn:/bin/sh -c "sleep 20; exec /etc/getty tty01 sc_m"

The inittab file consists of four colon separated fields:

ck:234:bootwait:/etc/asktimerc >/dev/console </dev/console 2<&1
  identifier:run levels:action:command

This is a powerful capability, but it is found only on System V variants of Unix. Another drawback is that there is no indication with /etc/inittab and the init command that the process has exited and restarted unless the process continuously dies and init prints a message on the console. The message typically is something like Command is respawning too rapidly. How can you provide a system independent method of monitoring and restarting critical system processes? The answer is procmon.

---

Note:  BSD-based operating systems, such as SunOS, BSD/OS from BSD Inc., and FreeBSD do not use /etc/inittab to control processes spawned by init.

---