Tuesday, 10 January 2017

The Reasons Why We Use Linux Kill Signals And Commands




Kill Commands
The kill commands (such as kill, xkill, etc.) are commands that use the the "kill()" system call. In other words, the command-line kill commands are wrappers for the kernel's "kill()" syscall.

kill
The kill command will kill a process using the kill signal and PID given by the user. To use the SIGKILL signal with "kill", type one of the following for a process with a PID of 1710.
Code:
kill -9 1710
kill -SIGKILL 1710
kill -KILL 1710

The kill command accepts either the signal number, partial name (omitting “SIG”) or name (signals have both a number and name that can be referenced). The name must be in all caps. However, some systems do not support partial names.

killall
The killall command kills all process with a particular name. For instance, Nautilus may be running several times. To kill all of them type "killall -SIGQUIT nautilus". Also, if Firefox is running once and the user does not know the PID, use the killall command - "killall -9 firefox". The killall command also uses case-sensitive kill signals (they are all uppercase). Below demonstrates what will happen when the kill signal is typed in lowercase. Notice that the command uses the "s" as a parameter and then it does not know what to do with the rest of the information. It then tries to use "igkill" as a kill signal, but no such signal exists.
Code:
collier@Nacho-Laptop:~$ killall -sigkill nautilus
igkill: unknown signal; killall -l lists signals.
pkill
This command is a lot like killall except it allows partial names. So, "pkill -9 unity" will kill any process whose name begins with "unity". pkill can also kill all processes owned by a particular user - “pkill -9 -u USERNAME”


xkill
This command allows users to kill a command by clicking the window. This kill command is offered by the X Server and is only usable on systems using X11. In a terminal, type "xkill" and then the cursor will change. Next, click a window to kill. The application should disappear and leave the system's memory. Then, the cursor will return to normal. Alternate display servers (like Weston and Mir) do not support xkill and do not have equivalents (at this time).

Signals
There are many kill signals that each serve a particular purpose. Typing "kill -l" will list the kill signals supported by that particular utility (explained in a moment). Notice that all kill signals begin with "SIG"; this means SIGnal.

Code:
kill -l
1) 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 17) SIGCHLD
18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN
22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO
30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1
36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5
40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9
44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13
52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9
56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5
60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1
64) SIGRTMAX
Yes, certain numbers are missing because those signals are not supported on my system or by that kill command, or they were discontinued. If you run the same command, you may have different numbers missing/available.

Here is a typically unknown trick. Many shells (such as BASH) have their own kill command that is separate from the system's kill command (/bin/kill). To see this on a system, type "kill -l", "kill -L", "/bin/kill -l", and "/bin/kill -L" in a terminal one at a time. It can be seen that the results are different between kill and /bin/kill. There are some signals and parameters supported by one and not the other. However, everyone has SIGHUP (1), SIGQUIT (3), SIGKILL (9), and SIGTERM (15). Those are the most common and useful signals. It is important to learn and memorize those four very well when administering Linux systems.

Kill-Signal-List.png 

Kill signals are not only used to close locked-up applications, but also stop software from performing unallowed tasks. This means some of these kill signals are part of security. Surprisingly, kill commands not only stop/kill processes but they also pause, continue, and restart processes.

A list of signals supported by the kernel can be found in /usr/include/linux/signal.h. This file may show that the signals come from two assembly libraries (/usr/include/asm/signal.h and /usr/include/asm/siginfo.h).

Signal Descriptions
NOTE: This is alphabetically sorted.
  • SIGABRT - This kill signal is the abort signal. Typically, a process will initiate this kill signal on itself.
  • SIGALRM - SIGALRM is sent when the real-time or clock-time timer expires.
  • SIGBUS - When a process is sent the SIGBUS signal, it is because the process caused a bus error. Commonly, these bus errors are due to a process trying to use fake physical addresses or the process has its memory alignment set incorrectly.
  • SIGCHLD - When a parent process loses its child process, the parent process is sent the SIGCHLD signal. This cleans up resources used by the child process. In computers, a child process is a process started by another process know as a parent.
  • SIGCONT - To make processes continue executing after being paused by the SIGTSTP or SIGSTOP signal, send the SIGCONT signal to the paused process. This is the CONTinue SIGnal. This signal is beneficial to Unix job control (executing background tasks).
  • SIGEMT - Processes receive this signal when an emulator trap occurs.
  • SIGFPE - Processes that divide by zero are killed using SIGFPE. Imagine if humans got the death penalty for such math. NOTE: The author of this article was recently taken out to the street and shot for dividing by zero. (^u^)
  • SIGHUP - The SIGHUP signal disconnects a process from the parent process. This an also be used to restart processes. For example, "killall -SIGHUP compiz" will restart Compiz. This is useful for daemons with memory leaks.
  • SIGILL - When a process performs a faulty, forbidden, or unknown function, the system sends the SIGILL signal to the process. This is the “ILLegal SIGnal”.
  • SIGINFO - Terminals may sometimes send status requests to processes. When this happens, processes will also receive this signal.
  • SIGINT - This signal is the same as pressing ctrl-c. On some systems, "delete" + "break" sends the same signal to the process. The process is interrupted and stopped. However, the process can ignore this signal.
  • SIGIO - An alias to SIGPOLL.
  • SIGIOT - This is an alias for SIGABRT.
  • SIGKILL - The SIGKILL signal forces the process to stop executing immediately. The program cannot ignore this signal. This process does not get to clean-up either.
  • SIGLOST - Processes trying to access locked files will get this signal. Many systems use SIGLOST as an alias for SIGPOLL especially since accessing locked files is an asynchronous I/O event.
  • SIGPIPE - When a process tries to write to a pipe that lacks an end connected to a reader, this signal is sent to the process. A reader is a process that reads data at the end of a pipe.
  • SIGPOLL - When a process causes an asynchronous I/O event, that process is sent the SIGPOLL signal. SIGPOLL and SIGIO are aliases. In the assembly source code, SIGIO is defined as "29" and SIGPOLL is defined as "SIGIO".
  • SIGPROF - SIGPROF is sent when CPU time used by the process and by the system on behalf of the process elapses.
  • SIGPWR - Power failures will cause the system to send this signal to processes (if the system is still on).
  • SIGQUIT - This is like SIGINT with the ability to make the process produce a core dump.
  • SIGRTMAX* - This is a set of signals that varies between systems. They are labeled SIGRTMAX-1, SIGRTMAX-2, SIGRTMAX-3, ......., and so on (usually up to 14). These are user-defined signals; they must be programmed in the Linux kernel's source code. That would require the user to know C/C++.
  • SIGRTMIN* - This is a set of signals that varies between systems. They are labeled SIGRTMIN+1, SIGRTMIN+2, SIGRTMIN+3, ......., and so on (usually up to 15). These are user-defined signals; they must be programmed in the Linux kernel's source code. That would require the user to know C/C++.
  • SIGSEGV - When an application has a segmentation violation, this signal is sent to the process.
  • SIGSTOP - This signal makes the operating system pause a process's execution. The process cannot ignore the signal.
  • SIGSYS - Processes that give a system call an invalid parameter will receive this signal.
  • SIGTERM - This signal requests a process to stop running. This signal can be ignored. The process is given time to gracefully shutdown. When a program gracefully shuts down, that means it is given time to save its progress and release resources. In other words, it is not forced to stop. SIGINT is very similar to SIGTERM.
  • SIGTRAP - This signal is used for debugging purposes. When a process has performed an action or a condition is met that a debugger is waiting for, this signal will be sent to the process.
  • SIGTSTP - This signal is like pressing ctrl-z. This makes a request to the terminal containing the process to ask the process to stop temporarily. The process can ignore the request.
  • SIGTTIN - When a process attempts to read from a tty (computer terminal), the process receives this signal.
  • SIGTTOU - When a process attempts to write from a tty (computer terminal), the process receives this signal.
  • SIGUNUSED - On many systems, this is an alias for SIGSYS.
  • SIGURG - When a process has urgent data to be read or the data is very large, the SIGURG signal is sent to the process.
  • SIGUSR1 - This indicates a user-defined condition. This signal can be set by the user by programming the commands in sigusr1.c. This requires the programmer to know C/C++.
  • SIGUSR2 - This indicates a user-defined condition.
  • SIGVTALRM - SIGVTALRM is sent when CPU time used by the process elapses.
  • SIGWINCH - When a process is in a terminal that changes its size, the process receives this signal.
  • SIGXCPU - When a process uses the CPU past the allotted time, the system sends the process this signal. SIGXCPU acts like a warning; the process has time to save the progress (if possible) and close before the system kills the process with SIGKILL.
  • SIGXFSZ - Filesystems have a limit to how large a file can be made. When a program tries to violate this limit, the system will send that process the SIGXFSZ signal.

Signals Defined in /usr/include/asm/signal.h (Linux 3.19.0-21-generic)
Code:
#define SIGHUP  1
#define SIGINT  2
#define SIGQUIT  3
#define SIGILL  4
#define SIGTRAP  5
#define SIGABRT  6
#define SIGIOT  6
#define SIGBUS  7
#define SIGFPE  8
#define SIGKILL  9
#define SIGUSR1  10
#define SIGSEGV  11
#define SIGUSR2  12
#define SIGPIPE  13
#define SIGALRM  14
#define SIGTERM  15
#define SIGSTKFLT  16
#define SIGCHLD  17
#define SIGCONT  18
#define SIGSTOP  19
#define SIGTSTP  20
#define SIGTTIN  21
#define SIGTTOU  22
#define SIGURG  23
#define SIGXCPU  24
#define SIGXFSZ  25
#define SIGVTALRM  26
#define SIGPROF  27
#define SIGWINCH  28
#define SIGIO  29
#define SIGPOLL  SIGIO
/*#define SIGLOST  29*/
#define SIGPWR  30
#define SIGSYS  31
#define SIGUNUSED  31
Users can use these kill signals using one of the many kill commands, such as pkill, xkill, etc. (if supported). When sending a signal to a process owned by another user (like Root), the user needs admin privileges and must use the sudo command. Be careful though, misuse of these signals can cause system damage. For instance, using SIGTERM on a GUI process like Compiz, X11, XFCE, Unity, Gnome-shell, etc. will make the system unviewable. However, some GUI processes will turn back on.

NOTE: If Compiz or some other important GUI utility freezes, crashes, etc., use SIGHUP to restart the GUI.

The Zero Signal
There is another signal that is supported by most systems, but is not list in the "kill -l" command. This is the "0" signal which is called "SIGT". This signal is used to see if the user can send signals to the specified PID/process. For instance, if a user owns a process and the process is running, then the command "kill -0 PID" will return "0". However, if the user does not own the specified PID or the PID is not assigned to a process, then the return value is "1".

Not all systems and kill commands support "0" or support it properly. For instance, on Ubuntu 15.04 (Vivid Vervet), the signal "0" and "SIGT" do not work with the "kill" command supplied by Bash or "/bin/kill".
Code:
collier@Nacho-Linux:~$ pidof firefox
21609
collier@Nacho-Linux:~$ /bin/kill 0 21609
Terminated
collier@Nacho-Linux:~$ /bin/kill SIGT 21609
kill: failed to parse argument: 'SIGT'
collier@Nacho-Linux:~$ kill 0 21609 # This killed Firefox
collier@Nacho-Linux:~$ pidof firefox
collier@Nacho-Linux:~$
Getting a Process's PID
To get the PID of a process (assuming the process name is known), try the below commands.
  • pidof PROCESS_NAME
  • ps aux | grep PROCESS_NAME
  • kill -p PROCESS_NAME
  • kill --pid PROCESS_NAME

NOTE: Not all systems and kill commands support "kill -p" or "kill --pid".

When combining a PID-finding command with the kill command, a user could type something like
Code:
kill -TERM `pidof geany`
Kill PID 0 and Negative PIDs
If the kill command is used and a PID of zero "0" is specified, then all processes with the same Group ID (GID) of the sender will be affected by the kill signal.

If the specified PID is negative one (-1) and the user is not using Root-privileges, then all of the processes with the same User ID (UID) as the sending user are killed. However, if the sender is Root or using Root-privileges, then all processes except system processes, processes with a Process Group ID (PGID) of 1, and the sending process are killed.

The System V standard specifies that negative PIDs more negative (smaller) than one (i.e. -2, -3, -4, ...) will act like PID -1, but in addition, kill only those processes with a process Group ID equal to the absolute value of the negative PID. This means PID -2 will affect processes with a Process Group ID (PGID) of 2 (since |-2| = 2 or abs(-2) = 2).


source:http://www.linux.org/

No comments:

Post a Comment