Testing UNIX Daemons

UNIX daemons are programs that run in the background, letting you do other work in the foreground. Len presents a "recipe" for testing them.


March 01, 2000
URL:http://www.drdobbs.com/testing-unix-daemons/184404033

Mar00: Testing UNIX Daemons

Len manages the Software Test and Quality Assurance Department for GTE Internetworking (formerly BBN). He can be contacted at [email protected].


UNIX daemons are programs that run in the background, letting you do other work in the foreground. Because daemons (supposedly short for the "Disk And Execution MONitor" program; see http://www.dict.org/) are independent of control from a terminal, they can either be started by processes, or by users without tying up a terminal as the daemon runs.

Interestingly, the noncomputer definition of "daemon" (an evil spirit or inner/private voice) applies to UNIX daemon programs. UNIX daemons have some characteristics in common with mythological demons, in that daemon programs skulk around unseen in the background just as a demon would. And daemons act like inner voices in that they can run continuously and, like a conscience, always be accessed.

You need to care about UNIX daemons because:

With all this in mind, in this article, I'll present a recipe for testing UNIX daemons.

Examples of Daemons

I'll start by examining Figure 1, which is sample output from ps (for more information on ps, see Advanced Programming in the UNIX Environment, by the late W. Richard Stevens, Addison-Wesley, 1992). The command-line options used specify that you want to see the status of all processes, including those owned by other users, that you want to see both processes that do and do not have controlling terminals, and that you want to see job control information. (The ps command syntax under UNIX systems based on BSD is "ps -axj." To receive the same output on UNIX systems based on SVR, the command is "ps -efjc." You can find a concise history of the development of the BSD and SRV variants in The Design of the UNIX Operating System, by Maurice J. Bach, Prentice Hall, 1990.)

To understand what Figure 1 shows you, I've added line numbers to make things easier to follow:

Line 1. The column titles indicate information in Table 1.

Line 2. The swapper process (often referred to as the "scheduler") allocates the CPU and memory to processes. Process 0 is created during the boot process, it then forks a child (process 1) and becomes the swapper process.

Line 3. The init process (process 1) initializes all other processes. The other processes either have init, or a child of init as a parent.

Line 4. The pagedaemon process controls the paging of virtual memory. Swapper, init, and pagedaemon are kernel processes (their code is part of the kernel).

Line 5. The syslogd daemon is used to report system messages.

Line 6. The cron (clock daemon) process executes other processes at specified times and dates.

Line 7. These days, a very common use of daemons is for programs to support and control networked communications between computer systems. In the past, separate daemons would be run for telnet, FTP, and other server processes. The 4.3 BSD release of UNIX introduced the superserver inetd daemon. Briefly, this server program handles incoming requests for multiple servers.

Lines 8-12. These telnet processes were created by inetd.

Line 13. The last line in Figure 1 is actually me, editing the temp file that I used to collect the ps output. The parent PID (16059) is that of my shell process as seen in the following ps output; see Figure 2. Also, the emacs job (PID 19690), unlike the daemon processes, does have a controlling terminal. It's the same terminal as the shell.

Design Review

The cheapest bug is the one that never gets coded. Accordingly, the first class of tests takes the form of a thorough design review.

As a first step in any design review, you should look for solid reference material. In the case of UNIX daemons (or any other UNIX networking programs), the best place to look is the series of UNIX network programming books by W. Richard Stevens. (In fact, much of this article relies on Chapter 126, "Daemon Processes and inetd Superserver," of Volume 1 of this series for technical reference information.)

What steps should the designer of a well-written UNIX daemon follow? You should:

Following these steps will result in a daemon that is more reliable and more testable than simply running any old program in the background and calling it a daemon.

Functional Tests

Once you've performed your design review, the next step is to verify the actual functions performed by the daemon, and any utilities built to support the daemon. The functions performed by a daemon will, of course, vary according to the daemon. There are, however, some constants you will want to look for in all daemons:

Stress Tests

Daemon programs are used to move data between processes or systems. In almost all cases, this involves moving large quantities of data. Accordingly, stress tests to measure and verify throughput and capacity should be a part of your daemon test suite.

The following are the sorts of characteristics you should look for:

System Tests

Just like any other program, daemons must coexist with the rest of the system. This means that they cannot attempt to allocate communications ports that are already in use by other programs and they cannot monopolize system resources to the extent that no other program can be run.

Also, recall that I extolled the virtue of writing to the system log by sending data to the syslogd daemon. There's one more thing you have to do to ensure that you will be successful in doing this: You have to make sure that your daemon starts after the syslogd daemon in the boot cycle. No kidding. I once actually saw a problem where a daemon consistently failed to start, but it only wrote error messages to the system log if it was run manually from the shell. Any attempt to start the daemon by rebooting the system failed to generate even one error message, even though the command syntax used in the startup script was identical to that entered by hand. It took us quite a while to realize that the daemon was trying to write to the system log, but that the syslogd daemon was not (yet) running.

Negative Tests

Once you've proven that the daemon functions correctly on its own and as a part of its greater system and that it can handle a traffic load, it's time to push the program to, and beyond, its limits through negative testing.

Security Tests

You may not think that security is a concern for the daemon you're testing, but if you're dealing with a networked product, then you have to worry about security. Security must be built into your products, and the platforms on which they run.

The most important aspect in testing the security of an Internet product or service, however, isn't the mechanics of testing for security holes. It is in the development of an attitude about security. Some people are squeamish about Internet security. They react to news stories about Internet break-ins by becoming paralyzed with fear and wishing their problems would just go away. They won't. As the use of the Internet increases, especially the use of the Internet for e-commerce, the number of pirates on the Internet will also increase. Just like the Internet, itself, security problems are here to stay. You will have to deal with them (see my article "Software Testing in the Internet Age," Software QA Magazine, March 1997; http://www.softtest.org/). How do you do this? You cannot safeguard your products on a one-shot basis. It's an ongoing effort. You make security a daily part of your development and test environment. The security you build into your products must evolve in reaction to new threats, just as they must evolve in response to new technological advances.

In terms of safeguarding a single daemon, you have to decide whether your daemon must run as root, or if it can run as another, less-privileged user. If it can run as a user other than root, then you must ensure that the user's account configuration restricts its access to only those files/directories that are necessary to run the daemon.

Where do you find out about Internet-related security alerts? The Internet, of course. In addition to there being bad people on the Internet, there are some good people out there, too. In 1988, a computer virus named "worm" caused major network outages. In response to this incident, an emergency response team was formed by the Defense Advanced Research Projects Agency (DARPA). From this team grew the Computer Emergency Response Team (CERT), now called the CERT Coordination Center. The CERT Coordination Center issues advisories on potential Internet security threats. For example, if a security hole is found in a specific program (such as the UNIX sendmail program), they investigate, document the risks, and make recommendations as to how the risks can be avoided. You can subscribe to advisory e-mail lists so that you'll automatically be kept informed as new holes are found and filled. You must also incorporate the latest security tools into your testing. You should always test your systems for potential security holes by using security scanner programs such as SATAN (a shareware program created by Wietse Venema and Dan Farmer) or the Internet Security Scanner (created by Christopher Klaus) and by staying up to date with the latest security information.

Conclusion

When you set out to plan and execute tests for a UNIX daemon program, you have to plan to test:

To verify the functions performed by the program, you can use the program's functional and design specifications as reference material. In order to verify whether the program can really serve as a daemon, you have to do some research into just how UNIX handles processes and terminals. In short, there's nothing magical or mystical about UNIX daemons. That is, once you understand how they work.

DDJ

Mar00: Testing UNIX Daemons

Figure 1: Annotated ps output.

Mar00: Testing UNIX Daemons

Figure 2: My processes as reported by ps.

Mar00: Testing UNIX Daemons

Table 1: Column titles.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.