UNIX System Administration Handbook - Evi Nemeth [42]
Table 4.3 summarizes all these variations. A prio is an absolute nice value, while an incr is relative to the niceness of the shell from which nice or renice is run. Wherever an -incr or a -prio is called for, you can use a double dash to enter negative values (e.g., --10). Only the shell nice understands plus signs (in fact, it requires them); leave them out in all other circumstances.
The most commonly niced process in the modern world is xntpd, the clock synchronization daemon. Since CPU promptness is critical to its mission, it usually runs at a nice value about 12 below the default (that is, at a higher priority than normal).
If a process goes berserk and drives the system’s load average to 65, you may need to use nice to start a high-priority shell before you can run commands to investigate the problem. Otherwise, your commands may never get a chance to run.
4.7 PS: MONITOR PROCESSES
ps is the system administrator’s main tool for monitoring processes. While versions of ps differ in their arguments and display, they all provide essentially the same information. Part of the enormous variation among versions of ps can be traced back to the wide gap between ps versions that originated in System V (Solaris, HP-UX) and those that descended from BSD (Red Hat, FreeBSD). However, ps is also a command that vendors tend to customize for other reasons. It’s closely tied to the kernel’s handling of processes, so it tends to reflect vendors’ underlying kernel changes.
ps can be used to show the PID, UID, priority, and control terminal of processes. It can also give information about how much memory a process is using, how much CPU time it has consumed, and its current status (running, stopped, sleeping, etc.). Zombies show up in a ps listing as Understanding ps output is an important administrative skill. Looking at a ps listing, you can determine (among other things) what processes are running on your system, how much CPU time and memory they’re using, and who owns each one. Implementations of ps have become hopelessly complex over the last few years. Several vendors have abandoned the attempt to define meaningful displays and made their pses completely configurable. With a little customization work, almost any desired output can be produced. The ps used by Red Hat is a trisexual and hermaphroditic version that understands several other ps’s option sets and uses an environment variable to tell it what universe it’s living in. Do not be alarmed by all of this complexity: it’s there mainly for kernel developers, not for system administrators. Although you will use ps frequently, you only need to know a few specific incantations. On Red Hat and FreeBSD, a useful overview of all the processes running on the system can be obtained with ps aux. Here’s an example of a ps aux on a machine running FreeBSD (the Red Hat output is slightly different): % ps aux USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 0 0.0 0.0 0 0 ?? DLs 8:35PM 0:00.06 (swapper) root 1 0.0 0.0 208 120 ?? Ss 8:35PM 0:00.20 init-s root 2 0.0 0.0 0 12 ?? DL 8:35PM 0:00.03 (pagedaemon) root 46 0.0 0.0 160 112 ?? Ss 8:37PM 0:01.45 syslogd root 66 0.0 0.0 228 152 ?? I 8:37PM 0:00.23 cron root 75 0.0 0.0 236 104 ?? IWs 8:37PM 0:00.02 lpd root 100 0.0 0.0 204 92 ?? Is 8:37PM 0:00.19 inetd evi 1251 0.0 0.0 320 256 p8 Is+ 1:50PM 0:00.47 -csh(csh) evi 1517 0.0 0.0 128 64 p8 S+ 3:17PM 0:00.03 manlogger evi 1520 0.0 0.0 332 224 pa R+ 3:17PM 0:00.04 ps-aux ... The meaning of each field is explained in Table 4.4. Table 4.4 Explanation of ps -aux output (FreeBSD) a. Arguments can be truncated; add the ww argument to prevent this. Programs can modify this info, so it’s not necessarily an accurate representation of the actual command line. Another useful set of arguments for Red Hat and FreeBSD is lax, which provides more technical information. It is also faster to run because it doesn