KILL(3P) POSIX Programmer's Manual KILL(3P)PROLOG
This manual page is part of the POSIX Programmer's Manual. The Linux
implementation of this interface may differ (consult the corresponding
Linux manual page for details of Linux behavior), or the interface may
not be implemented on Linux.
NAMEkill — send a signal to a process or a group of processes
SYNOPSIS
#include <signal.h>
int kill(pid_t pid, int sig);
DESCRIPTION
The kill() function shall send a signal to a process or a group of pro‐
cesses specified by pid. The signal to be sent is specified by sig and
is either one from the list given in <signal.h> or 0. If sig is 0 (the
null signal), error checking is performed but no signal is actually
sent. The null signal can be used to check the validity of pid.
For a process to have permission to send a signal to a process desig‐
nated by pid, unless the sending process has appropriate privileges,
the real or effective user ID of the sending process shall match the
real or saved set-user-ID of the receiving process.
If pid is greater than 0, sig shall be sent to the process whose
process ID is equal to pid.
If pid is 0, sig shall be sent to all processes (excluding an unspeci‐
fied set of system processes) whose process group ID is equal to the
process group ID of the sender, and for which the process has permis‐
sion to send a signal.
If pid is −1, sig shall be sent to all processes (excluding an unspeci‐
fied set of system processes) for which the process has permission to
send that signal.
If pid is negative, but not −1, sig shall be sent to all processes
(excluding an unspecified set of system processes) whose process group
ID is equal to the absolute value of pid, and for which the process has
permission to send a signal.
If the value of pid causes sig to be generated for the sending process,
and if sig is not blocked for the calling thread and if no other thread
has sig unblocked or is waiting in a sigwait() function for sig, either
sig or at least one pending unblocked signal shall be delivered to the
sending thread before kill() returns.
The user ID tests described above shall not be applied when sending
SIGCONT to a process that is a member of the same session as the send‐
ing process.
An implementation that provides extended security controls may impose
further implementation-defined restrictions on the sending of signals,
including the null signal. In particular, the system may deny the exis‐
tence of some or all of the processes specified by pid.
The kill() function is successful if the process has permission to send
sig to any of the processes specified by pid. If kill() fails, no sig‐
nal shall be sent.
RETURN VALUE
Upon successful completion, 0 shall be returned. Otherwise, −1 shall be
returned and errno set to indicate the error.
ERRORS
The kill() function shall fail if:
EINVAL The value of the sig argument is an invalid or unsupported sig‐
nal number.
EPERM The process does not have permission to send the signal to any
receiving process.
ESRCH No process or process group can be found corresponding to that
specified by pid.
The following sections are informative.
EXAMPLES
None.
APPLICATION USAGE
None.
RATIONALE
The semantics for permission checking for kill() differed between Sys‐
tem V and most other implementations, such as Version 7 or 4.3 BSD. The
semantics chosen for this volume of POSIX.1‐2008 agree with System V.
Specifically, a set-user-ID process cannot protect itself against sig‐
nals (or at least not against SIGKILL) unless it changes its real user
ID. This choice allows the user who starts an application to send it
signals even if it changes its effective user ID. The other semantics
give more power to an application that wants to protect itself from the
user who ran it.
Some implementations provide semantic extensions to the kill() function
when the absolute value of pid is greater than some maximum, or other‐
wise special, value. Negative values are a flag to kill(). Since most
implementations return [ESRCH] in this case, this behavior is not
included in this volume of POSIX.1‐2008, although a conforming imple‐
mentation could provide such an extension.
The unspecified processes to which a signal cannot be sent may include
the scheduler or init.
There was initially strong sentiment to specify that, if pid specifies
that a signal be sent to the calling process and that signal is not
blocked, that signal would be delivered before kill() returns. This
would permit a process to call kill() and be guaranteed that the call
never return. However, historical implementations that provide only the
signal() function make only the weaker guarantee in this volume of
POSIX.1‐2008, because they only deliver one signal each time a process
enters the kernel. Modifications to such implementations to support
the sigaction() function generally require entry to the kernel follow‐
ing return from a signal-catching function, in order to restore the
signal mask. Such modifications have the effect of satisfying the
stronger requirement, at least when sigaction() is used, but not neces‐
sarily when signal() is used. The standard developers considered making
the stronger requirement except when signal() is used, but felt this
would be unnecessarily complex. Implementors are encouraged to meet the
stronger requirement whenever possible. In practice, the weaker
requirement is the same, except in the rare case when two signals
arrive during a very short window. This reasoning also applies to a
similar requirement for sigprocmask().
In 4.2 BSD, the SIGCONT signal can be sent to any descendant process
regardless of user-ID security checks. This allows a job control shell
to continue a job even if processes in the job have altered their user
IDs (as in the su command). In keeping with the addition of the concept
of sessions, similar functionality is provided by allowing the SIGCONT
signal to be sent to any process in the same session regardless of user
ID security checks. This is less restrictive than BSD in the sense that
ancestor processes (in the same session) can now be the recipient. It
is more restrictive than BSD in the sense that descendant processes
that form new sessions are now subject to the user ID checks. A similar
relaxation of security is not necessary for the other job control sig‐
nals since those signals are typically sent by the terminal driver in
recognition of special characters being typed; the terminal driver
bypasses all security checks.
In secure implementations, a process may be restricted from sending a
signal to a process having a different security label. In order to
prevent the existence or nonexistence of a process from being used as a
covert channel, such processes should appear nonexistent to the sender;
that is, [ESRCH] should be returned, rather than [EPERM], if pid refers
only to such processes.
Existing implementations vary on the result of a kill() with pid indi‐
cating an inactive process (a terminated process that has not been
waited for by its parent). Some indicate success on such a call (sub‐
ject to permission checking), while others give an error of [ESRCH].
Since the definition of process lifetime in this volume of POSIX.1‐2008
covers inactive processes, the [ESRCH] error as described is inappro‐
priate in this case. In particular, this means that an application can‐
not have a parent process check for termination of a particular child
with kill(). (Usually this is done with the null signal; this can be
done reliably with waitpid().)
There is some belief that the name kill() is misleading, since the
function is not always intended to cause process termination. However,
the name is common to all historical implementations, and any change
would be in conflict with the goal of minimal changes to existing
application code.
FUTURE DIRECTIONS
None.
SEE ALSOgetpid(), raise(), setsid(), sigaction(), sigqueue(), wait()
The Base Definitions volume of POSIX.1‐2008, <signal.h>, <sys_types.h>
COPYRIGHT
Portions of this text are reprinted and reproduced in electronic form
from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
-- Portable Operating System Interface (POSIX), The Open Group Base
Specifications Issue 7, Copyright (C) 2013 by the Institute of Electri‐
cal and Electronics Engineers, Inc and The Open Group. (This is
POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) In the
event of any discrepancy between this version and the original IEEE and
The Open Group Standard, the original IEEE and The Open Group Standard
is the referee document. The original Standard can be obtained online
at http://www.unix.org/online.html .
Any typographical or formatting errors that appear in this page are
most likely to have been introduced during the conversion of the source
files to man page format. To report such errors, see https://www.ker‐
nel.org/doc/man-pages/reporting_bugs.html .
IEEE/The Open Group 2013 KILL(3P)
