Sams Teach Yourself Network Troubleshooting in 24 Hours:Hour 12 UNIX Networking Basics

Table of Contents

Although Microsoft has tried, NT has not quite eaten UNIX’s lunch yet. UNIX’s ability to reconfigure without rebooting and the way it keeps going and going and going garners it a good deal of respect from folks who run nonstop data centers. I’ve seen UNIX servers that have been continuously up for over two years without needing a reboot. (The UNIX administrator in question was a bit of a lunatic, because leaving any server up for that long is just playing with fire, but it’s still pretty impressive.)

Friendly Daemons

First a word about a UNIX server’s way of keeping track of the various programs running on it. You already know that Windows 95 shows you running programs on the system tray (the gray bar at the bottom of the screen). Well, a UNIX server typically has a couple hundred programs running at once—particularly because each client that connects to the server usually causes a separate program to fire off to serve the client. In Windows 95, that system tray would get pretty crowded! Instead, UNIX uses an internal process table that lists process numbers, the name of the processes, and other information.

A UNIX server, like your Windows 95 PC, can run many programs at once. Not all of them will interact with a user directly. Many of them run in the background. These background processes are called daemons. All UNIX services, whether Telnet, HTTP, or FTP, run as daemons.
When looking at a process listing, you can usually figure out which process is a daemon: It has a letter d at the end of its name. When talking about a daemon, you usually pronounce the d at the end, as in name-dee for named.

Suppose that a particular service is not running on a given UNIX server; say, for example, that the Web server doesn’t seem to be home. Rather than trying to reboot the server (other services would be interrupted by doing this), you might first investigate whether the Web server process is running and then start it if it’s not or stop it and restart it if it is. You usually need to be running as the super user (root) to stop or start processes.

You can cause a great deal of damage when running as the root user; you should use the su (super user) command to temporarily gain root privileges, run your commands, and then exit, rather than logging in as root. Again, you can contribute greatly to your confidence level if you install a play system on a PC—either Linux or another flavor.
Because the root prompt (#) is typically different than the normal prompt ($), I show it in the text to indicate commands that I would run as the root user.

Depending upon the type of UNIX you’re running, you would type one of the following commands to look at the process table:

ps -ef

ps -ax

What’s up with the -ef and the -ax? Well, these are flags that indicate to the ps (process status) program that you want to view everything in the process table. They’re just different on different systems. So, right away, you need a way to figure out which flag you need to use. Buck up! Most, if not all, UNIX systems have all the manual pages right on the system. The man (check manual pages) command can give you details on any command you want. For example, to get specific details on what those -ef and -ax flags with the ps command mean, as well as to find out what other flags are available, you would type this:
man ps

One of the best ways for you to learn UNIX is to use the man pages; to learn how to use the man command, you can type this:

man man

The ps command stands for process status. On a busy system, your screen will zoom by with zillions of processes. Fortunately, you can make the display pause, or, even better, search the table for what you’re looking for. Suppose you’re looking for the Web server, the http daemon, or httpd. (The http comes from http://, which you type when finding a Web page; it stands for Hypertext Transfer Protocol. Therefore, this httpd program is the Hypertext Transfer Protocol daemon.) You could type this:

ps -ax | grep httpd

You might get nothing back—that probably means that httpd has died, and you need to restart it. However, if it’s not dead (it’s just merely lost its mind), you might get this:

52 ? S   0:01 /usr/sbin/httpd

The first number is the process ID (or PID). This is the number you refer to when you want to do something to this process. For example, the commands for killing and restarting this process might look something like this:

$ ps -ax | grep httpd
   52  ?  S     0:01 /usr/sbin/httpd
$ su
Password:
# kill 52
# ps -ax | grep httpd
# /usr/sbin/httpd
# exit
$ ps -ef | grep httpd
  871 ? S   0:01 /usr/sbin/httpd

You’ll notice here that I don’t need to use su until I actually kill the process and restart it. Then I immediately exit the su session so that I keep my super user risk at a minimum. I also like to recheck the process table before and after I’ve restarted the daemon just to make sure it’s not out there after I kill it or to make sure that it is there after I restart it.

Table of Contents