1KILL(3P)                   POSIX Programmer's Manual                  KILL(3P)


6       This  manual  page is part of the POSIX Programmer's Manual.  The Linux
7       implementation of this interface may differ (consult the  corresponding
8       Linux  manual page for details of Linux behavior), or the interface may
9       not be implemented on Linux.


13       kill — send a signal to a process or a group of processes


16       #include <signal.h>
18       int kill(pid_t pid, int sig);


21       The kill() function shall send a signal to a process or a group of pro‐
22       cesses specified by pid.  The signal to be sent is specified by sig and
23       is either one from the list given in <signal.h> or 0. If sig is 0  (the
24       null  signal),  error  checking  is performed but no signal is actually
25       sent. The null signal can be used to check the validity of pid.
27       For a process to have permission to send a signal to a  process  desig‐
28       nated  by  pid,  unless the sending process has appropriate privileges,
29       the real or effective user ID of the sending process  shall  match  the
30       real or saved set-user-ID of the receiving process.
32       If  pid  is  greater  than  0,  sig  shall be sent to the process whose
33       process ID is equal to pid.
35       If pid is 0, sig shall be sent to all processes (excluding an  unspeci‐
36       fied  set  of  system processes) whose process group ID is equal to the
37       process group ID of the sender, and for which the process  has  permis‐
38       sion to send a signal.
40       If pid is −1, sig shall be sent to all processes (excluding an unspeci‐
41       fied set of system processes) for which the process has  permission  to
42       send that signal.
44       If  pid  is  negative,  but  not −1, sig shall be sent to all processes
45       (excluding an unspecified set of system processes) whose process  group
46       ID is equal to the absolute value of pid, and for which the process has
47       permission to send a signal.
49       If the value of pid causes sig to be generated for the sending process,
50       and if sig is not blocked for the calling thread and if no other thread
51       has sig unblocked or is waiting in a sigwait() function for sig, either
52       sig  or at least one pending unblocked signal shall be delivered to the
53       sending thread before kill() returns.
55       The user ID tests described above shall not  be  applied  when  sending
56       SIGCONT  to a process that is a member of the same session as the send‐
57       ing process.
59       An implementation that provides extended security controls  may  impose
60       further  implementation-defined restrictions on the sending of signals,
61       including the null signal. In particular, the system may deny the exis‐
62       tence of some or all of the processes specified by pid.
64       The kill() function is successful if the process has permission to send
65       sig to any of the processes specified by pid.  If kill() fails, no sig‐
66       nal shall be sent.


69       Upon successful completion, 0 shall be returned. Otherwise, −1 shall be
70       returned and errno set to indicate the error.


73       The kill() function shall fail if:
75       EINVAL The value of the sig argument is an invalid or unsupported  sig‐
76              nal number.
78       EPERM  The  process  does not have permission to send the signal to any
79              receiving process.
81       ESRCH  No process or process group can be found corresponding  to  that
82              specified by pid.
84       The following sections are informative.


87       None.


90       None.


93       The  semantics for permission checking for kill() differed between Sys‐
94       tem V and most other implementations, such as Version 7 or 4.3 BSD. The
95       semantics  chosen  for this volume of POSIX.1‐2008 agree with System V.
96       Specifically, a set-user-ID process cannot protect itself against  sig‐
97       nals  (or at least not against SIGKILL) unless it changes its real user
98       ID.  This choice allows the user who starts an application to  send  it
99       signals  even if it changes its effective user ID.  The other semantics
100       give more power to an application that wants to protect itself from the
101       user who ran it.
103       Some implementations provide semantic extensions to the kill() function
104       when the absolute value of pid is greater than some maximum, or  other‐
105       wise  special, value. Negative values are a flag to kill().  Since most
106       implementations return [ESRCH] in  this  case,  this  behavior  is  not
107       included  in  this volume of POSIX.1‐2008, although a conforming imple‐
108       mentation could provide such an extension.
110       The unspecified processes to which a signal cannot be sent may  include
111       the scheduler or init.
113       There  was initially strong sentiment to specify that, if pid specifies
114       that a signal be sent to the calling process and  that  signal  is  not
115       blocked,  that  signal  would  be delivered before kill() returns. This
116       would permit a process to call kill() and be guaranteed that  the  call
117       never return. However, historical implementations that provide only the
118       signal() function make only the weaker  guarantee  in  this  volume  of
119       POSIX.1‐2008,  because they only deliver one signal each time a process
120       enters the kernel.  Modifications to such  implementations  to  support
121       the  sigaction() function generally require entry to the kernel follow‐
122       ing return from a signal-catching function, in  order  to  restore  the
123       signal  mask.  Such  modifications  have  the  effect of satisfying the
124       stronger requirement, at least when sigaction() is used, but not neces‐
125       sarily when signal() is used. The standard developers considered making
126       the stronger requirement except when signal() is used,  but  felt  this
127       would be unnecessarily complex. Implementors are encouraged to meet the
128       stronger  requirement  whenever  possible.  In  practice,  the   weaker
129       requirement  is  the  same,  except  in  the rare case when two signals
130       arrive during a very short window. This reasoning  also  applies  to  a
131       similar requirement for sigprocmask().
133       In  4.2  BSD,  the SIGCONT signal can be sent to any descendant process
134       regardless of user-ID security checks.  This allows a job control shell
135       to  continue a job even if processes in the job have altered their user
136       IDs (as in the su command). In keeping with the addition of the concept
137       of  sessions, similar functionality is provided by allowing the SIGCONT
138       signal to be sent to any process in the same session regardless of user
139       ID security checks. This is less restrictive than BSD in the sense that
140       ancestor processes (in the same session) can now be the recipient.   It
141       is  more  restrictive  than  BSD in the sense that descendant processes
142       that form new sessions are now subject to the user ID checks. A similar
143       relaxation  of security is not necessary for the other job control sig‐
144       nals since those signals are typically sent by the terminal  driver  in
145       recognition  of  special  characters  being  typed; the terminal driver
146       bypasses all security checks.
148       In secure implementations, a process may be restricted from  sending  a
149       signal  to  a  process  having a different security label.  In order to
150       prevent the existence or nonexistence of a process from being used as a
151       covert channel, such processes should appear nonexistent to the sender;
152       that is, [ESRCH] should be returned, rather than [EPERM], if pid refers
153       only to such processes.
155       Existing  implementations vary on the result of a kill() with pid indi‐
156       cating an inactive process (a terminated  process  that  has  not  been
157       waited  for  by its parent). Some indicate success on such a call (sub‐
158       ject to permission checking), while others give an  error  of  [ESRCH].
159       Since the definition of process lifetime in this volume of POSIX.1‐2008
160       covers inactive processes, the [ESRCH] error as described  is  inappro‐
161       priate in this case. In particular, this means that an application can‐
162       not have a parent process check for termination of a  particular  child
163       with  kill().   (Usually this is done with the null signal; this can be
164       done reliably with waitpid().)
166       There is some belief that the name  kill()  is  misleading,  since  the
167       function  is not always intended to cause process termination. However,
168       the name is common to all historical implementations,  and  any  change
169       would  be  in  conflict  with  the  goal of minimal changes to existing
170       application code.


173       None.


176       getpid(), raise(), setsid(), sigaction(), sigqueue(), wait()
178       The Base Definitions volume of POSIX.1‐2008, <signal.h>, <sys_types.h>
181       Portions of this text are reprinted and reproduced in  electronic  form
182       from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
183       -- Portable Operating System Interface (POSIX),  The  Open  Group  Base
184       Specifications Issue 7, Copyright (C) 2013 by the Institute of Electri‐
185       cal and Electronics Engineers,  Inc  and  The  Open  Group.   (This  is
186       POSIX.1-2008  with  the  2013  Technical Corrigendum 1 applied.) In the
187       event of any discrepancy between this version and the original IEEE and
188       The  Open Group Standard, the original IEEE and The Open Group Standard
189       is the referee document. The original Standard can be  obtained  online
190       at http://www.unix.org/online.html .
192       Any  typographical  or  formatting  errors that appear in this page are
193       most likely to have been introduced during the conversion of the source
194       files  to  man page format. To report such errors, see https://www.ker
195       nel.org/doc/man-pages/reporting_bugs.html .
199IEEE/The Open Group                  2013                             KILL(3P)