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



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


NNAAMMEE
       kill -- send a signal to a process or a group of processes

SSYYNNOOPPSSIISS
       #include <signal.h>

       int kill(pid_t _p_i_d, int _s_i_g);

DDEESSCCRRIIPPTTIIOONN
       The _k_i_l_l() function shall send a signal to a process or a group of
       processes specified by _p_i_d.  The signal to be sent is specified by _s_i_g
       and is either one from the list given in _<_s_i_g_n_a_l_._h_> or 0. If _s_i_g 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
       _p_i_d.

       For a process to have permission to send a signal to a process
       designated by _p_i_d, 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 _p_i_d is greater than 0, _s_i_g shall be sent to the process whose
       process ID is equal to _p_i_d.

       If _p_i_d is 0, _s_i_g shall be sent to all processes (excluding an
       unspecified set of system processes) whose process group ID is equal to
       the process group ID of the sender, and for which the process has
       permission to send a signal.

       If _p_i_d is -1, _s_i_g shall be sent to all processes (excluding an
       unspecified set of system processes) for which the process has
       permission to send that signal.

       If _p_i_d is negative, but not -1, _s_i_g shall be sent to all processes
       (excluding an unspecified set of system processes) whose process group
       ID is equal to the absolute value of _p_i_d, and for which the process has
       permission to send a signal.

       If the value of _p_i_d causes _s_i_g to be generated for the sending process,
       and if _s_i_g is not blocked for the calling thread and if no other thread
       has _s_i_g unblocked or is waiting in a _s_i_g_w_a_i_t() function for _s_i_g, either
       _s_i_g or at least one pending unblocked signal shall be delivered to the
       sending thread before _k_i_l_l() 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
       sending 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
       existence of some or all of the processes specified by _p_i_d.

       The _k_i_l_l() function is successful if the process has permission to send
       _s_i_g to any of the processes specified by _p_i_d.  If _k_i_l_l() fails, no
       signal shall be sent.

RREETTUURRNN VVAALLUUEE
       Upon successful completion, 0 shall be returned. Otherwise, -1 shall be
       returned and _e_r_r_n_o set to indicate the error.

EERRRROORRSS
       The _k_i_l_l() function shall fail if:

       EEIINNVVAALL The value of the _s_i_g argument is an invalid or unsupported
              signal number.

       EEPPEERRMM  The process does not have permission to send the signal to any
              receiving process.

       EESSRRCCHH  No process or process group can be found corresponding to that
              specified by _p_i_d.

       _T_h_e _f_o_l_l_o_w_i_n_g _s_e_c_t_i_o_n_s _a_r_e _i_n_f_o_r_m_a_t_i_v_e_.

EEXXAAMMPPLLEESS
       None.

AAPPPPLLIICCAATTIIOONN UUSSAAGGEE
       None.

RRAATTIIOONNAALLEE
       The semantics for permission checking for _k_i_l_l() differed between
       System 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
       signals (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 _k_i_l_l() function
       when the absolute value of _p_i_d is greater than some maximum, or
       otherwise special, value. Negative values are a flag to _k_i_l_l().  Since
       most implementations return [[EESSRRCCHH]] in this case, this behavior is not
       included in this volume of POSIX.1-2008, although a conforming
       implementation could provide such an extension.

       The unspecified processes to which a signal cannot be sent may include
       the scheduler or _i_n_i_t.

       There was initially strong sentiment to specify that, if _p_i_d specifies
       that a signal be sent to the calling process and that signal is not
       blocked, that signal would be delivered before _k_i_l_l() returns. This
       would permit a process to call _k_i_l_l() and be guaranteed that the call
       never return. However, historical implementations that provide only the
       _s_i_g_n_a_l() 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 _s_i_g_a_c_t_i_o_n() function generally require entry to the kernel
       following 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 _s_i_g_a_c_t_i_o_n() is used, but not
       necessarily when _s_i_g_n_a_l() is used. The standard developers considered
       making the stronger requirement except when _s_i_g_n_a_l() 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 _s_i_g_p_r_o_c_m_a_s_k().

       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 _s_u 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
       signals 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, [[EESSRRCCHH]] should be returned, rather than [[EEPPEERRMM]], if _p_i_d refers
       only to such processes.

       Existing implementations vary on the result of a _k_i_l_l() with _p_i_d
       indicating an inactive process (a terminated process that has not been
       waited for by its parent). Some indicate success on such a call
       (subject to permission checking), while others give an error of
       [[EESSRRCCHH]].  Since the definition of process lifetime in this volume of
       POSIX.1-2008 covers inactive processes, the [[EESSRRCCHH]] error as described
       is inappropriate in this case. In particular, this means that an
       application cannot have a parent process check for termination of a
       particular child with _k_i_l_l().  (Usually this is done with the null
       signal; this can be done reliably with _w_a_i_t_p_i_d().)

       There is some belief that the name _k_i_l_l() 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.

FFUUTTUURREE DDIIRREECCTTIIOONNSS
       None.

SSEEEE AALLSSOO
       _g_e_t_p_i_d(), _r_a_i_s_e(), _s_e_t_s_i_d(), _s_i_g_a_c_t_i_o_n(), _s_i_g_q_u_e_u_e(), _w_a_i_t()

       The Base Definitions volume of POSIX.1-2008, <<ssiiggnnaall..hh>>, <<ssyyss__ttyyppeess..hh>>

CCOOPPYYRRIIGGHHTT
       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
       Electrical 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.kernel.org/doc/man-pages/reporting_bugs.html .



IEEE/The Open Group                  2013                              KILL(3)
