Classic Shell Scripting - Arnold Robbins [191]
The seven-stage pipeline handles the report preparation:
The output from ps contains lines like this: USER COMMAND
root sched
root /etc/init
root /usr/lib/nfs/nfsd
...
jones dtfile
daemon /usr/lib/nfs/statd
...
The sed command deletes the initial header line.
The egrep command selects the usernames to be displayed. We clear the EGREP_OPTIONS environment variable to avoid conflicts in its interpretation by different GNU versions of egrep.
The sort stage sorts the data by username and then by process.
The uniq command attaches leading counts of duplicated lines and eliminates duplicates.
A second sort stage sorts the data again, this time by username, then by descending count, and finally by process name.
The awk command formats the data into neat columns, and removes repeated usernames.
* * *
[1] Available at ftp://ftp.groupsys.com/pub/top/. Another implementation for GNU/Linux systems only is available at http://procps.sourceforge.net/.
Process Control and Deletion
Well-behaved processes ultimately complete their work and terminate with an exit( ) system call. Sometimes, however, it is necessary to terminate a process prematurely, perhaps because it was started in error, requires more resources than you care to spend, or is misbehaving.
The kill command does the job, but it is misnamed. What it really does is send a signal to a specified running process, and with two exceptions noted later, signals can be caught by the process and dealt with: it might simply choose to ignore them. Only the owner of a process, or root, or the kernel, or the process itself, can send a signal to it. A process that receives a signal cannot tell where it came from.
ISO Standard C defines only a half-dozen signal types. POSIX adds a couple of dozen others, and most systems add more, offering 30 to 50 different ones. You can list them like this example on an SGI IRIX system:
$ kill -l
List supported signal names (option lowercase L)
HUP INT QUIT ILL TRAP ABRT EMT FPE KILL BUS SEGV SYS PIPE ALRM TERM
USR1 USR2 CHLD PWR WINCH URG POLL STOP TSTP CONT TTIN TTOU VTALRM PROF
XCPU XFSZ UME RTMIN RTMIN+1 RTMIN+2 RTMIN+3 RTMAX-3 RTMAX-2 RTMAX-1
RTMAX
Most are rather specialized, but we've already used a few of the more common ones in trap commands in shell scripts elsewhere in this book.
Each program that handles signals is free to make its own interpretation of them. Signal names reflect conventions, not requirements, so there is some variation in exactly what a given signal means to a particular program.
Uncaught signals generally cause termination, although STOP and TSTP normally just suspend the process until a CONT signal requests that it continue execution. You might use STOP and CONT to delay execution of a legitimate process until a less-busy time, like this:
$ top
Show top resource consumers
...
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
17787 johnson 9 58 0 125M 118M cpu/3 109:49 93.67% cruncher
...
$ kill -STOP 17787
Suspend process
$ sleep 36000 && kill -CONT 17787 &
Resume process in 10 hours
Deleting Processes
For deleting processes, it is important to know about only four signals: ABRT (abort), HUP (hangup), KILL, and TERM (terminate).
Some programs prefer to do some cleanup before they exit: they generally interpret a TERM signal to mean clean up quickly and exit. kill sends that signal if you do not specify one. ABRT is like TERM, but may suppress cleanup actions, and may produce a copy of the process memory image in a core, program .core, or core.PID file.
The HUP signal similarly requests termination, but with many daemons, it often means that the process should stop what it is doing, and then get ready for new work, as if it were freshly started. For example, after you make changes to a configuration file, a HUP signal makes the daemon reread that file.
The two signals that no process can catch or ignore are KILL and STOP. These two signals are always delivered immediately. For sleeping processes,[3] however,