System Administrator Toolkit: Process Management Tips
Learn how to get the UNIX® process information you need. For all system administrators, it is one of the most basic requirements to understand the processes that are running on their UNIX systems. A standard list of processes is useful, but the information it provides is malformed or does not contain the required process or information. The ability to select specific types of data from a list of processes makes it easier to manage tasks. In this article, you will learn how to extend the list of processes to improve the readability of information, or to provide summaries and information that are not readily available elsewhere. You'll also see a standardized way to get process information across different UNIX platforms.
0 Reviews:
Martin Brown ([email protected]), freelance writer to ask
May 28, 2006
Develop and deploy your next application on the IBM Bluemix cloud platform.
Get started with your trial
About this series
Typically, UNIX® administrators have a set of utilities, techniques, and systems that he/she often uses to assist in managing processes. There are some important utilities, command line chains, and scripts that can be used to simplify various processing processes. Some of these tools come from the operating system, and most of the techniques derive from long-term experience and the need to simplify the work of the system administrator. This series of articles focuses on maximizing the use of tools available in a variety of UNIX environments, including ways to simplify administrative tasks in heterogeneous environments.
Use
ps
ps
The command-line tool lists the processes that are running. The tool exists in all of the UNIX variants and generally works the same basic way, requesting the kernel to request a list of running processes and then reporting the list of processes and their properties, such as memory usage, run time, and other details.
ps
Tools are actually a very powerful tool, although many administrators may use only one or two of the available options to see the information they need. You can use the built-in command-line options to get more information from the command, and even ps
combine the pipeline with other commands to get the exact information you need.
List all Processes
Even if you are logged in as root, ps
the standard output lists only the processes that you are running. Depending on your UNIX environment, the basic command-line options that are used to obtain information about other processes in the system, or change the information displayed, are based on the BSD or AT&T,SYSV UNIX base section. In a BSD-based UNIX environment, the output includes the process ID, terminal, status, time (execution time in the CPU, seconds, not the time the process started), and the command executed, as shown in Listing 1.
Listing 1 lists the processes on the BSD UNIX variant
$ ps PID TT STAT time COMMAND 391 P5 S 0:00.24/bin/bash 9165 P5 s+ 0:00.50 Emacs 476 P6 s 0:01.03/bin/bash 9299 P6 s 0:00.09 xterm 9319 P6 s 0:00.07 xterm 9423 P6 s 0:00.12 ftp Atuin 9513 p6 r+ 0:00.01 PS 9301 P7 ss+ 0:00.01/usr/x11r6/bin/luit 9302 P8 ss+ 0:00.03 bash 9321 p9 ss+ 0:00.01/usr/x11r6/bin/luit 9322 pa ss+ 0:00.02 Bash
In a SVR4 environment, you provide fewer columns (you do not have process state information), as shown in Listing 2 below.
Listing 2. List the processes on the SVR4 UNIX variant
$ ps PID TTY time CMD19915 pts/3 00:00:00 bash29145 pts/3 00:00:00 emacs32256 pts/3 00:00:00 emacs26986 PTS/3 00:00:00 xterm31303 pts/3 00:00:00 ftp31358 pts/3 00:00:00 PS
To get a list of all the processes that are running on the system, you need to use different command-line options depending on the UNIX variant you are using. In BSD UNIX, the -a
command-line option lists the processes for all users, including yourself. However, this list does not include processes that do not control the terminal (such as those that start executing at startup, daemons, and processes that are cron
part of the work). To get a list of all running processes, you must use -A
command-line options (see Listing 3).
Listing 3. List all processes on the BSD system
$ ps-a PID TT STAT time COMMAND 1?? S<s 0:15.47/sbin/launchd 23?? Ss 0:00.02/sbin/dynamic_pager-f/private/var/vm/swapfile 27?? Ss 0:00.95 kextd 49?? Ss 0:05.17/USR/SBIN/CONFIGD 50?? Ss 0:01.89/usr/sbin/coreaudiod 51?? Ss 0:04.40/usr/sbin/diskarbitrationd 52?? Ss 0:00.08/usr/sbin/memberd-x 53?? Ss 0:02.80/usr/sbin/securityd 55?? Ss 11:03.59/usr/sbin/notifyd 57?? Ss 0:01.13/usr/sbin/directoryservice ... 8051 p2 s+ 0:00.61 ssh [email protected] 292 P3 Ss 0:00.02 Bash 372 p3 s+ 0:00.42 ssh [email  ;p rotected] 312 P4 ss+ 0:00.03 Bash 332 P5 Ss 0:00.03 bash 391 P5 S 0:00.24/bin/bash 9165 P5 s+ 0:00.50 Emacs 352 P6 Ss 0:00.04 bash 476 p6 s 0:01.04/bin/bash 9299 p6 s 0:00.09 xterm 9319 P6 s 0:00.07 xterm 9423 P6 s 0:00.14 ftp Atuin 9520 p6 r+ 0:00.01 ps-a 9301 P7 ss+ 0:00.01/usr/X11r6/bin/luit 9302 P8 ss+ 0:00.03 bash 9321 p9 ss+ 0:00.01/usr/x11r6/bin/luit 9322 pa ss+ 0:00.02 Bash
-A
The command-line option is -a
equivalent to the simultaneous use and -x
option, which -a
shows the process that owns the control terminal and -x
shows the process without the control terminal.
In the SVR4 variant, the command-line options that show all running processes, whether or not they have control terminals, are -e
. From the process shown, it is equivalent to the BSD -A
option. You can see an example of the output in Listing 4.
Listing 4. List of processes in the SVR4 environment
$ ps-e PID TTY time CMD 0? 15:24 sched 1? 0:00 init 2? 0:00 pageout 3? 0:00 Fsflush 308? 0:00 devfsadm 7? 0:06 Svc.star 9? 0:10 svc.conf 506? 0:00 Htt_serv 260? 0:00 rpcbind 259? 0:00 cron ? 0:00 Dhcpagen 282 console 0:00 ttymon 267? 0:00 lockd ? 0:00 statd ? 0:00 sysevent ... 462? 0:00 smcboot 464? 0:00 smcboot 463? 0:00 smcboot 473? 0:00 htt 552? 0:00 in.telne 527? 0:00 dmispd 548? 0:01 SNMPD
The difference between the output is the columns of information displayed, but you can modify them by specifying the columns you want.
List specified information
ps
The tool contains a number of standard display column sets. For example, in SVR4, it is often used ps -ef
to get more detailed information about the list of processes, including the parent process ID, processor utilization, start time, and more verbose command lines, as shown in Listing 5.
Listing 5. Extended output
ps-ef UID PID PPID C stime TTY time CMD root 0 0 0 15:56:26? 15:24 sched Root 1 0 0 15:56:26? 0:00/sbin/init Root 2 0 0 15:56:26? 0:00 pageout Root 3 0 0 15:56:26? 0:00 Fsflush Root 308 1 0 15:57:09? 0:00 DEVFSADMD Root 7 1 0 15:56:29? 0:06/lib/svc/bin/svc.startd. Root 562 1 0 15:58:17? 0:00/usr/lib/sendmail-bd-q15m root 576 555 1 16:01:47 pts/1 0:00 ps-ef root 416 1 0 15:57:14 ? 0:00/USR/SBIN/SYSLOGD Smmsp 561 1 0 15:58:17? 0:00/usr/lib/sendmail-ac-q15m. Root 552 283 0 15:57:47? 0:00/USR/SBIN/IN.TELNETD Root 527 1 0 15:57:22? 0:00/USR/LIB/DMI/DMISPD Root 548 1 0 15:57:24? 0:01/USR/SFW/SBIN/SNMPD
For BSD environments, it is common to add -l
an option that produces a "long" output for each process, as shown in Listing 6.
Listing 6. Show more detailed information in BSD
$ ps-aluid PID PPID CPU PRI NI VSZ RSS wchan STAT TT time COMMAND 0 9165 391 0 0 5 7896 6376- s+ P5 0:00.50 emacs501 352 349 0 0 27784 - Ss P6 0:00.04 Bash 0 476 352 0 0 27784 - S P6 0:01.05/bin/bash 0 9299 476 0 0 44988 1880- S p6 0:00.09 xterm 0 9319 476 0 31 0 44988 1888- s P6 0:00.07 xterm 0 9423 476 0 0 27504 488 - s P6 0:00.15 ftp atuin< C51/>0 9540 476 0 0 27384 504- r+ p6 0:00.01 ps-axl 0 9301 9299 0 0 27332 452- ss+ P7 0:00.01/usr/x11r6/bin/luit 0 9302 9301 0 0 27784 888- ss+ P8 0:00.03 bash 0 9321 9319 0 0 27332 452- ss+ P9 0:00.01/usr/x11r6/bin/luit 0 9322 9321 0 0 27784 888- ss+ pa 0:00.02 Bash
The problem with these options is that although they show more information, they are not always particularly useful, or when looking for a particular process, contain information that you do not want to see in a disturbing display.
Fortunately, all versions ps
also include the ability to specify which columns to display. You can use this command extensively, whether it's extracting only the information you need, or using it in a heterogeneous environment to create standardized output across different UNIX environments.
To use this feature, you can use -o
command-line options and list the columns you want to display, with a comma-delimited delimiter. Although there are some differences in the range of columns that can be selected, most of the columns are standard in different versions of UNIX. For example, all variants have PID, ppid (Parent process ID), command, RSS (resident set size or memory usage), and priority.
When used, you can use -o
to select columns and their display order. For example, to get PID, Ppid, and Commond, you can use it in BSD, -opid,ppid,command
as shown in Listing 7, or in SVR4 -opid,ppid,comm
, as shown in Listing 8.
Listing 7. Select a specific column in BSD
$ ps-o pid,ppid,command pid ppid command 391 332/bin/bash 9165 391 emacs
Listing 8. Select a specific column in the SVR4
$ ps-opid,ppid,comm PID ppid COMMAND 555 552-sh 622 555 PS
After you select the column you want, you may choose the order in which the information is arranged. ps
The default setting is to arrange the list of processes based on the process ID, but this may hide the information you are looking for. When looking for memory hungry processes, it is more useful to arrange display results by memory usage than by process ID.
Some ps
variants support this situation by using command-line options. BSD variants use the -m
option to sort by memory usage or use -r
to sort by CPU usage. Many SVR4 variants do not have a definitive solution to the problem, but similar results can be generated in all environments by combining ps
and grouping sort
them. For example, to get a list of processes sorted by CPU usage, you can use the command shown in Listing 9 in BSD.
Listing 9. Track CPU usage in BSD
$ ps-a-o pid,%cpu,command|sort-n +1...358 0.1 ftp11425 0.1/bin/bash28684 0.3 trivial-rewrite-n rewrite-t Unix-u 356 0.4 ssh 354 0.5 as23988 1.1 emacs 136 14.6 cc1plus26306 23.6 CPP
In SVR4, it needs to be %cpu
changed pcpu
, and the command is the same in other respects (see listing 10).
Listing 10. Tracking CPU usage in SVR4
$ ps-e-opid,pcpu,comm|sort-n +1 ... 3 0.1 fsflush 555 0.1-sh 627 0.2 sort 628 0.2 PS
The chain of command is possible because the order of the process list has been specified, so you can sort by these columns to get the information you really want. If you want to use different criteria to find a process, there are other scenarios available.
List specific processes
Obviously, after you get the list of running processes, you might want to list specific processes. An obvious way to do this is to ps
combine the output with the grep
information needed to extract it. In some UNIX variants, this can be done through a number of specific utilities, for example pgrep
, but it is also useful if you are looking for specific commands grep
.
$ ps-ef|grep Bash
ps
The command also supports displaying processes based on more explicit criteria, such as user ID, parent process, or control terminal. For example, the -U
command-line option qualifies the process list to display only the processes for the specified user name. For example, to display the process currently owned by the root user, see listing 11.
Listing 11. List processes based on user
$ ps-u rootpid TTY time CMD 0? 15:24 sched 1? 0:00 init 2? 0:00 pageout 3? 0:02 Fsflush 308? 0:00 devfsadm 7? 0:06 Svc.star ... 552? 0:00 in.telne 527? 0:00 dmispd 629 pts/1 0:00 PS 548? 0:01 SNMPD
To get all the processes for the specified terminal, use -t
, as shown in Listing 12.
Listing 12. List processes by terminal
$ ps-t 3PID TTY time CMD19915 pts/3 00:00:00 bash29145 pts/3 00:00:00 emacs32256 pts/3 00:00:00 Emacs
After you have this information, you might want to use it to manipulate the process accordingly.
Send a signal to multiple threads
When you find the process you want to query, one of the most common commands is kill
. It sends a specific signal to one or more processes. For cases where a daemon with multiple threads or child threads is started, you can attempt to send a signal to the parent process to send a signal to all processes. However, this approach is not valid for all daemons and applications.
Obviously, you want to avoid manually picking out these processes. Some UNIX variants have a named pkill
tool that can send the same signal to processes that meet a particular pattern or other criteria, such as a terminal, a process group, a user ID, and a list of group IDs.
This basic operation can be simulated in the form of links,,, ps
grep
awk
xargs
and kill
commands, sending signals to multiple processes that satisfy a particular command pattern. For example, to send a signal to a process that contains "httpd" in all commands kill
, you can use:
$ ps-e-opid,command |grep Httpd|awk ' {print $} ' |xargs kill-9
If you study a single element, it will be easier to understand.
$ ps-e-opid,command
This command displays a list of all the processes that are running (this is in the SVR4 system, and should be used in BSD -A
). It shows only the process ID and the command being executed. No additional information is required, and using more verbose output may introduce other aspects of the text that match the search criteria.
$ ps-e-opid,command |grep httpd
This command extracts only the processes that contain httpd in the command (because the only other information generated in the process list is the process ID):
$ ps-e-opid,command |grep Httpd|awk ' {print $} '
By using awk
, only filtering removes the first parameter in the printout, that is, the process ID.
$ ps-e-opid,command |grep Httpd|awk ' {print $} ' |xargs kill-9
xargs
The command receives a blank character delimited list of items (where whitespace characters include carriage returns, line feeds, tabs, and one or more spaces), and formats it as a parameter list to pass to the specified command, in this case the kill
command.
It is best to put it in a script and take an appropriate name, for example ( pkill
or killbyname
). You can set the script to receive two parameters, signal and match text, and even consider the operating system differences, as shown in Listing 13.
Listing 13. Sending a message to a process through a command string
#!/bin/shhosttype= ' uname-s ' signal=$1string=$2if [-z] $-o-z "$"]then Echo Usage: $ SIGNAL string exit 1fic ASE $HOSTTYPE in darwin| BSD) ps-a-opid,command | grep $STRING | awk ' {print $;} ' | Xargs kill $SIGNAL ;; Linux| solaris| Aix| HP-UX) ps-e-opid,command | grep $STRING | awk ' {print $;} ' | Xargs kill $SIGNAL ;; Esac
The basic techniques shown here can be used for other similar collations.
Calculation of memory usage
ps
The tool also provides two columns that we are not currently involved in. The RSS column provides the "resident set size" of the process, which is the amount of physical memory used by the process, and is also an indication of how much real ram the process is consuming. The VSZ column details the total amount of memory that the process is using, including the allocated internal storage, but is typically swapped to disk. For most ps
variants, these two columns are more commonly used.
Identifying these two data is a good way to better understand memory usage. If you combine to ps
grep
Select a particular process and use it awk
to calculate the total amount, you can get a single application or how much physical memory and virtual memory the application and its child processes are consuming.
For example, to determine the bash
physical memory and virtual memory used by the process, you can use the command in Listing 14.
Listing 14. Use
ps
And
awk
Calculation of memory usage
$ ps-a-o rss,vsz,command|grep Bash | awk ' {RSS + = $ '; vsz + = $ $} END {print "real:", RSS, "virtual:", vsz} ' Real: 4004 virtual: 305624
This is especially useful when diagnosing problems with memory and swap usage.
Using a Shell that is compatible with job control
It is common for a typical system administrator to run one or more two or more specific tasks at any one time. Although there may be more than one connection to the server at any point, whether it be a multi-terminal window (e.g. through xterm) or another terminal, or a remote connection via SSH or Telnet, it is sometimes necessary to control or monitor multiple processes in the active Shell or environment.
All shells support appending hyphens (&) at the end of the command to enable the command to run automatically in the background. But sometimes you want to put an interactive application (such as an editor) in the background so that you can run a shell command and then return to the editor session.
This ability to control the background process, called job control, is a standard feature of the Korn shell, C shell, and open source shells such as bash and zsh.
To implement basic job control that runs in the background every time a command is started in the Shell, the command (which can be any legitimate command line, even an inline script) gives the job reference ID.
$ find/-name "core" >/tmp/corelist 2>&1 & [3] 11957
You can use jobs
the command to get a list of jobs that are running in the background, as shown in Listing 15.
Listing 15. Use
jobs
Command
$ jobs[1]- Stopped emacs mcslp/intranet/news.pm[2]+ Stopped Emacs Mcslp/intranet/media.pm[3] Running Find/-name "core" >/tmp/corelist 2>&1 &
In the list, the second emacs
command uses the + sign callout. This means that the Shell considers it to be the current active job. The previously initiated find
work is not active, because it does not require interaction (although it produces output, it does not require input to continue), and therefore is not an active process. The first Emacs process uses --
annotations to describe the command that the Shell thinks it was previously active. These jobs can be referenced separately using %+
and %-
strings.
You can fg
%+
%-
switch any running job to a foreground process by entering the job number or the job string (,). If the reference is omitted, the Shell switches to the current active work.
To suspend the currently running process, press control-z. You can reconfigure it with the following code:
ftp> [3]+ Stopped ftp Atuin
It can be used in conjunction with many different commands and applications. For most simple commands that run in the Shell, such as ls
or find
, it should also be valid. Note that the job is marked as Stopped. This means that the execution of the command has been paused. To switch the command to a background process, use the bg
command. As with fg
, the bg
job reference is accepted or, without parameters, the currently active job as its argument is defaulted. If the command requires input (such as an editor, FTP, and so on), bg
when you press ENTER again after the command, you are warned that the process is temporarily suspended (see listing 16).
Listing 16. A warning that the process is temporarily suspended
$ bg[3]+ ftp Atuin &$ [3]+ Stopped
Note that if the background command produces output and does not redirect it, it will still output to the screen even if the command is placed in the background through job control.
In a busy environment, job control is one of the easiest ways to manage and control multiple background jobs, or to quickly exit the editor and other commands and return to the active shell (relative to running a new shell).
When you want to access content outside of the job control shell or standard shell in a single user or recovery model of a UNIX system, you must ensure that there is a static link to the shell in a standard binary directory (such as/bin or/sbin, which is dedicated to static link binaries for the application) Copy. This will ensure that the Shell is available before the two-level file system is loaded.
Running processes reliably in the background
Sometimes you want to run scripts, utilities, or command lines in the background. However, most systems will terminate commands running in the background when the user disconnects or log off, and if you want to log in first, start the command, and then log off, you will find that you are not looking for a result.
The termination of the command execution is frustrating in cases where a restart is required, or if the daemon is reinitialized or does not have an automatic daemon, or relies on a separate script to start and manage the execution of the daemon application. The MySQL mysqld_safe
script is a good example of how it works in this way.
To prevent an application from automatically terminating when you log off, you can use the nohup
command as a prefix for the command line or tool you want to run, as follows:
$ nohup find/-name Core
nohup
standard output and standard errors are automatically written to nohup.out
a file named in the current directory, unless the output of the command is specifically redirected.
Use standard redirection to output to your own files, but keep in mind that you want to redirect both output and error streams, for example:
$ nohup find/-name Core >/tmp/corefind.out 2>&1
I find myself always using it unconsciously nohup
to run any command I think lasts longer than 2 or 3 minutes, even if it's running in the console. This can be largely related to automatic redirection of output, rather than the ability to prevent termination if the connection fails.
Summarize
Using the techniques described in this article, you can quickly find the UNIX processes you want and the information about them. If you are in a heterogeneous environment, you can also use command-line options to standardize the generated output, making it easier for you to find the process you want.
Process Management Tips