Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Kill (command)
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
===Unix and Unix-like=== In [[Unix]] and [[Unix-like]] operating systems, <code>kill</code> is a [[command (computing)|command]] used to send a [[Signal (IPC)|signal]] to a process. By default, the message sent is the [[SIGTERM|termination signal]], which requests that the process [[exit (system call)|exit]]. But ''kill'' is something of a misnomer; the signal sent may have nothing to do with process killing. The <code>kill</code> command is a [[wrapper function|wrapper]] around the '''<code>kill()</code>''' [[system call]], which sends [[Signal (IPC)|signals]] to processes or [[process group]]s on the system, referenced by their numeric [[process identifier|process IDs]] (PIDs) or [[process group]] IDs (PGIDs). <code>kill</code> is always provided as a standalone utility as defined by the [[POSIX]] standard. However, most [[Unix shell|shells]] have [[Shell builtin|built-in]] <code>kill</code> commands that may slightly differ from it.<ref>{{cite web | title = Bash Reference Manual: Job Control Builtins | url = https://www.gnu.org/software/bash/manual/html_node/Job-Control-Builtins.html | website = The GNU Project | access-date = 2015-02-24 }}</ref><ref>{{cite web | title = zsh: 17. Shell Builtin Commands | url = http://zsh.sourceforge.net/Doc/Release/Shell-Builtin-Commands.html | access-date = 2015-02-24 }}</ref> There are many different signals that can be sent (see ''[[signal (IPC)|signal]]'' for a full list), although the signals in which users are generally most interested are [[SIGTERM]] ("terminate") and [[SIGKILL]] ("kill"). The default signal sent is SIGTERM. Programs that handle this signal can do useful cleanup operations (such as saving configuration information to a file) before quitting. However, many programs do not implement a special handler for this signal, and so a default signal handler is called instead. Other times, even a process that has a special handler has gone awry in a way that prevents it from properly handling the signal. All signals except for SIGKILL and [[SIGSTOP]] ("stop") can be "intercepted" by the process, meaning that a special function can be called when the program receives those signals. The two exceptions SIGKILL and SIGSTOP are only seen by the host system's [[Kernel (operating system)|kernel]], providing reliable ways of controlling the execution of processes. SIGKILL kills the process, and SIGSTOP pauses it until a [[SIGCONT]] ("continue") is received.<ref>{{cite web | url = http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html | title = <signal.h> | website = The Open Group Base Specifications Issue 7 | access-date = 2015-02-24 }}</ref> Unix provides security mechanisms to prevent unauthorized users from killing other processes. Essentially, for a process to send a signal to another, the owner of the signaling process must be the same as the owner of the receiving process or be the [[superuser]]. The available signals all have different names, and are mapped to certain numbers. The specific mapping between numbers and signals can vary between Unix implementations. SIGTERM is often numbered 15 while SIGKILL is often numbered 9. ====Examples==== A process can be sent a [[SIGTERM]] signal in four ways (the process ID is '1234' in this case): <syntaxhighlight lang="bash"> kill 1234 kill -s TERM 1234 kill -TERM 1234 kill -15 1234 </syntaxhighlight> The process can be sent a [[SIGKILL]] signal in three ways: <syntaxhighlight lang="bash"> kill -s KILL 1234 kill -KILL 1234 kill -9 1234 </syntaxhighlight> Other useful signals include HUP, TRAP, INT, [[SIGSEGV|SEGV]] and ALRM. HUP sends the [[SIGHUP]] signal. Some daemons, including [[Apache HTTP Server|Apache]] and [[Sendmail]], re-read [[configuration file]]s upon receiving SIGHUP, so the kill command may be used for this too. A [[SIGINT (POSIX)|SIGINT]] signal can be generated very simply by pressing [[Control-C|{{keypress|CTRL|C}}]] in most [[Unix shell]]s. It is also common for [[Control-Z|{{keypress|CTRL|Z}}]] to be mapped to [[SIGTSTP]] ("terminal stop"), and for [[Control-\|{{keypress|CTRL|\}}]] (backslash) to be mapped to [[SIGQUIT]], which can force a program to do a [[core dump]]. ====Related programs==== *[[killall]] - on some variations of Unix, such as [[Solaris (operating system)|Solaris]], this utility is automatically invoked when the system is going through a [[Shutdown (computing)|shutdown]]. It behaves much like the kill command above, but instead of sending a signal to an individual process, the signal is sent to all processes on the system. However, on others such as [[IRIX]], [[Linux]], and [[FreeBSD]], an argument is supplied specifying the name of the process (or processes) to kill. For instance, to kill a process such as an instance of the [[XMMS]] music player invoked by <code>xmms</code>, the user would run the command <code>killall xmms</code>. This would kill all processes named <code>xmms</code>, and is equivalent to <code>kill `pidof xmms`</code> on systems like Solaris. *[[pkill]] - signals processes based on name and other attributes. It was introduced in Solaris 7 and has since been reimplemented for Linux, [[NetBSD]] and [[OpenBSD]]. pkill makes killing processes based on their name much more convenient: e.g. to kill a process named ''firefox'' without pkill (and without [[pgrep]]), one would have to type <code>kill `ps --no-headers -C firefox -o pid`</code> whereas with pkill, one can simply type <code>pkill firefox</code>. *[[xkill]] - if called without any parameters, the mouse cursor changes from an arrow to an "x" icon, and the user can click on a window to force the X server to close the connection with the client owning the window. This often causes the process to terminate when it detects that its connection to the X server has been closed.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)