• Choose a category
• All
• Classic-Fiction

See page 766 for more information about runaway processes.

You can identify processes that use excessive CPU time by looking at the output of ps. If it is obvious that a user process is consuming more CPU than can reasonably be expected, investigate the process. Step one is to contact the process’s owner and ask what’s going on. If the owner can’t be found, you will have to do some poking around of your own. Although you should normally avoid looking into users’ home directories, it is acceptable when you are trying to track down the source code of a runaway process to find out what it’s doing.

There are two reasons to find out what a process is trying to do before tampering with it. First, the process may be both legitimate and important to the user. It’s unreasonable to kill processes at random just because they happen to use a lot of CPU. Second, the process may be malicious or destructive. In this case, you’ve got to know what the process was doing (e.g., cracking passwords) so you can fix the damage.

If the reason for a runaway process’s existence can’t be determined, suspend it with a STOP signal and send email to the owner explaining what has happened. The process can be restarted later with a CONT signal. Be aware that some processes can be ruined by a long sleep, so this procedure is not always entirely benign. For example, a process may wake to find that some of its network connections have been broken.

If a process is using an excessive amount of CPU but appears to be doing something reasonable and working correctly, you should renice it to a higher nice value (lower priority) and ask the owner to do the nicing in the future.

Runaway processes that produce output can fill up an entire filesystem, causing numerous problems. When a filesystem fills up, lots of messages will be logged to the console and attempts to write to the filesystem will produce error messages.

The first thing to do in this situation is to stop the process that was filling up the disk. If you have been keeping a reasonable amount of breathing room on the disk, you can be fairly sure that something is amiss when it suddenly fills up. There’s no command analogous to ps that will tell you who’s consuming disk space at the fastest rate, but there are several tools that can identify files that are currently open and the processes that are using them. See the information on fuser and lsof starting on page 63 for more information.

You may want to suspend all suspicious-looking processes until you find the one that’s causing the problem, but remember to restart the innocents when you are done. When you find the offending process, remove the files it was creating.

An old and well-known prank is to start an infinite loop from the shell that does:

while 1

mkdir adir

cd adir

touch afile

end

This program occasionally shows up running from an unprotected login or from a terminal that was left logged in. It does not consume much actual disk space, but it fills up the filesystem’s inode table and prevents other users from creating new files. There is not much you can do except clean up the aftermath and warn users to protect their accounts. Because the directory tree that is left behind by this little jewel is usually too large for rm -r to handle, you may have to write a script that descends to the bottom of the tree and then removes directories as it backs out.

If the problem occurs in /tmp and you have set up /tmp as a separate filesystem, you can reinitialize /tmp with newfs instead of attempting to delete individual files. See Chapter 8 for more information about the management of filesystems.

1. Pages are the units in which memory is managed, usually 1K to 8K in size.

2. At least initially. If the original parent dies, init (process 1) becomes the new parent. See page 48.

3. Actually, they’re not all system calls. Usually, all but one are library routines.

4. The functions of and can be reassigned to other keys