# kill

## 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.
    


## NAME



           kill — 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
           processes 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
           designated 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
           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 _pid_ is -1, _sig_ shall be sent to all processes (excluding an
           unspecified 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 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 _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 signal 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
                  signal 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
           System V and most other implementations, such as Version 7 or 4.3
           BSD. The semantics chosen for this volume of POSIX.1‐2017 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 _kill_()
           function when the absolute value of _pid_ is greater than some
           maximum, or otherwise 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‐2017, although a conforming implementation 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‐2017, 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 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 _sigaction_() is used, but not
           necessarily 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
           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, **[ESRCH]** should be returned,
           rather than **[EPERM]** , if _pid_ refers only to such processes.
    
           Historical implementations varied on the result of a _kill_() with
           _pid_ indicating a zombie process. Some indicated success on such a
           call (subject to permission checking), while others gave an error
           of **[ESRCH]**.  Since the definition of process lifetime in this
           volume of POSIX.1‐2017 covers zombie processes, the **[ESRCH]** error
           as described is inappropriate in this case and implementations
           that give this error do not conform. This means that an
           application cannot have a parent process check for termination of
           a particular child by sending it the null signal with _kill_(), but
           must instead use _waitpid_() or _waitid_().
    
           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.
    


* * *