1KILL(3P) POSIX Programmer's Manual KILL(3P)
2
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.
10
12 kill — send a signal to a process or a group of processes
13
15 #include <signal.h>
16 int kill(pid_t pid, int sig);
18
20 The kill() function shall send a signal to a process or a group of pro‐
21 cesses specified by pid. The signal to be sent is specified by sig and
22 is either one from the list given in <signal.h> or 0. If sig is 0 (the
23 null signal), error checking is performed but no signal is actually
24 sent. The null signal can be used to check the validity of pid.
25 For a process to have permission to send a signal to a process desig‐
27 nated by pid, unless the sending process has appropriate privileges,
28 the real or effective user ID of the sending process shall match the
29 real or saved set-user-ID of the receiving process.
30 If pid is greater than 0, sig shall be sent to the process whose
32 process ID is equal to pid.
33 If pid is 0, sig shall be sent to all processes (excluding an unspeci‐
35 fied set of system processes) whose process group ID is equal to the
36 process group ID of the sender, and for which the process has permis‐
37 sion to send a signal.
38 If pid is -1, sig shall be sent to all processes (excluding an unspeci‐
40 fied set of system processes) for which the process has permission to
41 send that signal.
42 If pid is negative, but not -1, sig shall be sent to all processes
44 (excluding an unspecified set of system processes) whose process group
45 ID is equal to the absolute value of pid, and for which the process has
46 permission to send a signal.
47 If the value of pid causes sig to be generated for the sending process,
49 and if sig is not blocked for the calling thread and if no other thread
50 has sig unblocked or is waiting in a sigwait() function for sig, either
51 sig or at least one pending unblocked signal shall be delivered to the
52 sending thread before kill() returns.
53 The user ID tests described above shall not be applied when sending
55 SIGCONT to a process that is a member of the same session as the send‐
56 ing process.
57 An implementation that provides extended security controls may impose
59 further implementation-defined restrictions on the sending of signals,
60 including the null signal. In particular, the system may deny the exis‐
61 tence of some or all of the processes specified by pid.
62 The kill() function is successful if the process has permission to send
64 sig to any of the processes specified by pid. If kill() fails, no sig‐
65 nal shall be sent.
66
68 Upon successful completion, 0 shall be returned. Otherwise, -1 shall be
69 returned and errno set to indicate the error.
70
72 The kill() function shall fail if:
73 EINVAL The value of the sig argument is an invalid or unsupported sig‐
75 nal number.
76 EPERM The process does not have permission to send the signal to any
78 receiving process.
79 ESRCH No process or process group can be found corresponding to that
81 specified by pid.
82 The following sections are informative.
84
86 None.
87
89 None.
90
92 The semantics for permission checking for kill() differed between Sys‐
93 tem V and most other implementations, such as Version 7 or 4.3 BSD. The
94 semantics chosen for this volume of POSIX.1‐2017 agree with System V.
95 Specifically, a set-user-ID process cannot protect itself against sig‐
96 nals (or at least not against SIGKILL) unless it changes its real user
97 ID. This choice allows the user who starts an application to send it
98 signals even if it changes its effective user ID. The other semantics
99 give more power to an application that wants to protect itself from the
100 user who ran it.
101 Some implementations provide semantic extensions to the kill() function
103 when the absolute value of pid is greater than some maximum, or other‐
104 wise special, value. Negative values are a flag to kill(). Since most
105 implementations return [ESRCH] in this case, this behavior is not
106 included in this volume of POSIX.1‐2017, although a conforming imple‐
107 mentation could provide such an extension.
108 The unspecified processes to which a signal cannot be sent may include
110 the scheduler or init.
111 There was initially strong sentiment to specify that, if pid specifies
113 that a signal be sent to the calling process and that signal is not
114 blocked, that signal would be delivered before kill() returns. This
115 would permit a process to call kill() and be guaranteed that the call
116 never return. However, historical implementations that provide only the
117 signal() function make only the weaker guarantee in this volume of
118 POSIX.1‐2017, because they only deliver one signal each time a process
119 enters the kernel. Modifications to such implementations to support
120 the sigaction() function generally require entry to the kernel follow‐
121 ing return from a signal-catching function, in order to restore the
122 signal mask. Such modifications have the effect of satisfying the
123 stronger requirement, at least when sigaction() is used, but not neces‐
124 sarily when signal() is used. The standard developers considered making
125 the stronger requirement except when signal() is used, but felt this
126 would be unnecessarily complex. Implementors are encouraged to meet the
127 stronger requirement whenever possible. In practice, the weaker
128 requirement is the same, except in the rare case when two signals
129 arrive during a very short window. This reasoning also applies to a
130 similar requirement for sigprocmask().
131 In 4.2 BSD, the SIGCONT signal can be sent to any descendant process
133 regardless of user-ID security checks. This allows a job control shell
134 to continue a job even if processes in the job have altered their user
135 IDs (as in the su command). In keeping with the addition of the concept
136 of sessions, similar functionality is provided by allowing the SIGCONT
137 signal to be sent to any process in the same session regardless of user
138 ID security checks. This is less restrictive than BSD in the sense that
139 ancestor processes (in the same session) can now be the recipient. It
140 is more restrictive than BSD in the sense that descendant processes
141 that form new sessions are now subject to the user ID checks. A similar
142 relaxation of security is not necessary for the other job control sig‐
143 nals since those signals are typically sent by the terminal driver in
144 recognition of special characters being typed; the terminal driver
145 bypasses all security checks.
146 In secure implementations, a process may be restricted from sending a
148 signal to a process having a different security label. In order to
149 prevent the existence or nonexistence of a process from being used as a
150 covert channel, such processes should appear nonexistent to the sender;
151 that is, [ESRCH] should be returned, rather than [EPERM], if pid refers
152 only to such processes.
153 Historical implementations varied on the result of a kill() with pid
155 indicating a zombie process. Some indicated success on such a call
156 (subject to permission checking), while others gave an error of
157 [ESRCH]. Since the definition of process lifetime in this volume of
158 POSIX.1‐2017 covers zombie processes, the [ESRCH] error as described is
159 inappropriate in this case and implementations that give this error do
160 not conform. This means that an application cannot have a parent
161 process check for termination of a particular child by sending it the
162 null signal with kill(), but must instead use waitpid() or waitid().
163 There is some belief that the name kill() is misleading, since the
165 function is not always intended to cause process termination. However,
166 the name is common to all historical implementations, and any change
167 would be in conflict with the goal of minimal changes to existing
168 application code.
169
171 None.
172
174 getpid(), raise(), setsid(), sigaction(), sigqueue(), wait()
175 The Base Definitions volume of POSIX.1‐2017, <signal.h>, <sys_types.h>
177
179 Portions of this text are reprinted and reproduced in electronic form
180 from IEEE Std 1003.1-2017, Standard for Information Technology -- Por‐
181 table Operating System Interface (POSIX), The Open Group Base Specifi‐
182 cations Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of
183 Electrical and Electronics Engineers, Inc and The Open Group. In the
184 event of any discrepancy between this version and the original IEEE and
185 The Open Group Standard, the original IEEE and The Open Group Standard
186 is the referee document. The original Standard can be obtained online
187 at http://www.opengroup.org/unix/online.html .
188 Any typographical or formatting errors that appear in this page are
190 most likely to have been introduced during the conversion of the source
191 files to man page format. To report such errors, see https://www.ker‐
192 nel.org/doc/man-pages/reporting_bugs.html .
193IEEE/The Open Group 2017 KILL(3P)