Red Hat System Administration I
Use commands to kill and communicate with processes, define the characteristics of a daemon process, and stop user sessions and processes.
A signal is a software interrupt that is delivered to a process. Signals report events to an executing program. Events that generate a signal can be an error, an external event (an I/O request or an expired timer), or by the explicit use of a signal-sending command or keyboard sequence.
The following table lists the fundamental signals that system administrators use for routine process management. Refer to signals by their short (HUP) or proper (SIGHUP) name.
Table 8.2. Fundamental process management signals
| Signal | Name | Definition |
|---|---|---|
| 1 | HUP |
Hangup : Reports termination of the controlling process of a terminal. Also requests process re-initialization (configuration reload) without termination. |
| 2 | INT |
Keyboard interrupt : Causes program termination. It can be blocked or handled. Sent by pressing the INTR (Interrupt) key sequence (Ctrl+c). |
| 3 | QUIT |
Keyboard quit : Similar to SIGINT; adds a process dump at termination. Sent by pressing the QUIT key sequence (Ctrl+\). |
| 9 | KILL |
Kill, unblockable : Causes abrupt program termination. It cannot be blocked, ignored, or handled; consistently fatal. |
| 15 default | TERM |
Terminate : Causes program termination. Unlike SIGKILL, it can be blocked, ignored, or handled. The "clean" way to ask a program to terminate; it allows the program to complete essential operations and self-cleanup before termination. |
| 18 | CONT |
Continue : Sent to a process to resume if stopped. It cannot be blocked. Even if handled, it always resumes the process. |
| 19 | STOP |
Stop, unblockable : Suspends the process. It cannot be blocked or handled. |
| 20 | TSTP |
Keyboard stop : Unlike SIGSTOP, it can be blocked, ignored, or handled. Sent by pressing the suspend key sequence (Ctrl+z). |
Note
Signal numbers vary between Linux hardware platforms, but signal names and meanings are standard. It is advised to use signal names rather than numbers when signaling. The numbers that are discussed in this section are for x86_64 architecture systems.
Each signal has a default action, which is usually one of the following actions:
Term: Terminate a program (exit) immediately.Core: Save a program's memory image (core dump), and then terminate.Stop: Stop a running program (suspend) and wait to continue (resume).
Programs react to the expected event signals by implementing handler routines to ignore, replace, or extend a signal's default action.
You can signal the current foreground process by pressing a keyboard control sequence to suspend (Ctrl+z), kill (Ctrl+c), or core dump (Ctrl+\) the process. However, you might use signal-sending commands to send signals to background processes in a different session.
You can specify signals either by name (for example, with the -HUP or -SIGHUP options) or by number (with the related -1 option). Users can kill their processes, but root privilege is required to kill processes that other users own.
The kill command uses a PID number to send a signal to a process. Despite its name, you can use the kill command to send any signal, not just those signals for terminating programs. You can use the kill command -l option to list the names and numbers of all available signals.
[user@host ~]$kill -l1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM 16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP ...output omitted... [user@host ~]$ps aux | grep job5194 0.0 0.1 222448 2980 pts/1 S 16:39 0:00 /bin/bash /home/user/bin/control job1 5199 0.0 0.1 222448 3132 pts/1 S 16:39 0:00 /bin/bash /home/user/bin/control job2 5205 0.0 0.1 222448 3124 pts/1 S 16:39 0:00 /bin/bash /home/user/bin/control job3 5430 0.0 0.0 221860 1096 pts/1 S+ 16:41 0:00 grep --color=auto job [user@host ~]$kill 5194[user@host ~]$ps aux | grep jobuser 5199 0.0 0.1 222448 3132 pts/1 S 16:39 0:00 /bin/bash /home/user/bin/control job2 user 5205 0.0 0.1 222448 3124 pts/1 S 16:39 0:00 /bin/bash /home/user/bin/control job3 user 5783 0.0 0.0 221860 964 pts/1 S+ 16:43 0:00 grep --color=auto job [1] Terminated control job1 [user@host ~]$kill -9 5199[user@host ~]$ps aux | grep jobuser 5205 0.0 0.1 222448 3124 pts/1 S 16:39 0:00 /bin/bash /home/user/bin/control job3 user 5930 0.0 0.0 221860 1048 pts/1 S+ 16:44 0:00 grep --color=auto job [2]- Killed control job2 [user@host ~]$kill -SIGTERM 5205user 5986 0.0 0.0 221860 1048 pts/1 S+ 16:45 0:00 grep --color=auto job [3]+ Terminated control job3
Use the pkill command to signal one or more processes that match selection criteria. Selection criteria can be a command name, a process that a specific user owns, or all system-wide processes.
Processes and sessions can be individually or collectively signaled. To terminate all processes for one user, use the pkill command.
Because the initial process in a login session (session leader) is designed to handle session termination requests and to ignore unintended keyboard signals, killing all of a user's processes and login shells requires the SIGKILL signal.
By default, the pkill command sends the SIGTERM signal to each process instead of listing them on stdout.
First, use the pgrep command to identify the PID numbers to kill. This command operates similarly to the pkill command, including most of the same options, except that the pgrep command lists processes rather than killing them.
Use the pgrep command with the -l option to list the process names and IDs. Use either command with the -u option to specify the ID of the user who owns the processes.
[root@host ~]#pgrep -l -u bob6964 bash 6998 sleep 6999 sleep 7000 sleep [root@host ~]#pkill -SIGKILL -u bob[root@host ~]#pgrep -l -u bob
When processes that require attention are in the same login session, killing all of a user's processes might not be needed. Use the w command to determine the controlling terminal for the session, and then kill only the processes that reference the same terminal ID.
Unless SIGKILL is specified, the session leader (here, the Bash login shell) successfully handles and survives the termination request, but terminates all other session processes.
Use the -t option to match processes with a specific terminal ID.
[root@host ~]#pgrep -l -u bob7391 bash 7426 sleep 7427 sleep 7428 sleep [root@host ~]#w -u bobUSER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT bob tty3 18:37 5:04 0.03s 0.03s -bash [root@host ~]#pkill -t tty3[root@host ~]#pgrep -l -u bob7391 bash [root@host ~]#pkill -SIGKILL -t tty3[root@host ~]#pgrep -l -u bob[root@host ~]#
Important
Administrators commonly use SIGKILL.
It is always fatal, because the SIGKILL signal cannot be handled or ignored. However, it forces termination without allowing the killed process to run self-cleanup routines. Red Hat recommends sending SIGTERM first, and then trying SIGINT; and only if both fail, trying again with SIGKILL.
You can apply the same selective process termination with parent and child process relationships. Use the pstree command to view a process tree for the system or a single user. Use the parent process's PID to kill all children that it created. The parent Bash login shell survives this time, because the signal is directed only at its child processes.
[root@host ~]#pstree -p bobbash(8391)─┬─sleep(8425) ├─sleep(8426) └─sleep(8427) [root@host ~]#pkill -P 8391[root@host ~]#pgrep -l -u bobbash(8391) [root@host ~]#pkill -SIGKILL -P 8391[root@host ~]#pgrep -l -u bobbash(8391)
The killall command can signal multiple processes, based on their command name.
[user@host ~]$ps aux | grep job5194 0.0 0.1 222448 2980 pts/1 S 16:39 0:00 /bin/bash /home/user/bin/control job1 5199 0.0 0.1 222448 3132 pts/1 S 16:39 0:00 /bin/bash /home/user/bin/control job2 5205 0.0 0.1 222448 3124 pts/1 S 16:39 0:00 /bin/bash /home/user/bin/control job3 5430 0.0 0.0 221860 1096 pts/1 S+ 16:41 0:00 grep --color=auto job [user@host ~]$killall control[1] Terminated control job1 [2]- Terminated control job2 [3]+ Terminated control job3 [user@host ~]$
To terminate background jobs, use the kill command and specify the job number.
Use the jobs command to find the job number of the process to terminate.
[user@host ~]$jobs[1]- Running sleep 500 & [2]+ Running sleep 1000 & [user@host ~]$
Terminate a specific job by using the kill command. Prefix the job number with a percent sign (%).
[user@host ~]$kill -SIGTERM %1[user@host ~]$jobs[2]+ Running sleep 1000 &
You might need to log out other users for various reasons. Some possible scenarios: the user committed a security violation; the user might have overused resources; the user has an unresponsive system; or the user has improper access to materials. In these cases, you must terminate their session by using signals administratively.
First, to log off a user, identify the login session to be terminated. Use the w command to list user logins and currently running processes. Note the TTY and FROM columns to determine the closing sessions.
All user login sessions are associated with a terminal device (TTY). If the device name is pts/, then it is a pseudo-terminal that is associated with a graphical terminal window or a remote login session. If it is Ntty, then the user is on a system console, an alternative console, or another directly connected terminal device.N
[user@host ~]$ w -f
12:43:06 up 27 min, 5 users, load average: 0.03, 0.17, 0.66
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root tty2 12:26 14:58 0.04s 0.04s -bash
bob tty3 12:28 14:42 0.02s 0.02s -bash
user pts/1 desktop.example.com 12:41 2.00s 0.03s 0.03s w
[user@host ~]$Discover how long a user has been on the system by viewing the session login time. CPU resources that current jobs consume, including background tasks and child processes, are in the JCPU column for each session. Current foreground process CPU consumption is in the PCPU column.
References
kill(1), killall(1), pgrep(1), pkill(1), pstree(1), signal(7), and w(1) man pages
For further reading, refer to Signal Handling at https://www.gnu.org/software/libc/manual/pdf/libc.pdf#Signal%20Handling
For further reading, refer to Processes at https://www.gnu.org/software/libc/manual/pdf/libc.pdf#Processes
