247 lines
13 KiB
HTML
247 lines
13 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org">
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<link type="text/css" rel="stylesheet" href="style.css"><!-- Generated by The Open Group's rhtm tool v1.2.1 -->
|
|
<!-- Copyright (c) 2001 The Open Group, All Rights Reserved -->
|
|
<title>kill</title>
|
|
</head>
|
|
<body bgcolor="white">
|
|
<script type="text/javascript" language="JavaScript" src="../jscript/codes.js">
|
|
</script>
|
|
|
|
<basefont size="3"> <a name="kill"></a> <a name="tag_03_323"></a><!-- kill -->
|
|
<!--header start-->
|
|
<center><font size="2">The Open Group Base Specifications Issue 6<br>
|
|
IEEE Std 1003.1-2001<br>
|
|
Copyright © 2001 The IEEE and The Open Group, All Rights reserved.</font></center>
|
|
|
|
<!--header end-->
|
|
<hr size="2" noshade>
|
|
<h4><a name="tag_03_323_01"></a>NAME</h4>
|
|
|
|
<blockquote>kill - send a signal to a process or a group of processes</blockquote>
|
|
|
|
<h4><a name="tag_03_323_02"></a>SYNOPSIS</h4>
|
|
|
|
<blockquote class="synopsis">
|
|
<div class="box"><code><tt><sup>[<a href="javascript:open_code('CX')">CX</a>]</sup> <img src="../images/opt-start.gif" alt=
|
|
"[Option Start]" border="0"> #include <<a href="../basedefs/signal.h.html">signal.h</a>><br>
|
|
<br>
|
|
int kill(pid_t</tt> <i>pid</i><tt>, int</tt> <i>sig</i><tt>); <img src="../images/opt-end.gif" alt="[Option End]" border=
|
|
"0"></tt></code></div>
|
|
|
|
<tt><br>
|
|
</tt></blockquote>
|
|
|
|
<h4><a name="tag_03_323_03"></a>DESCRIPTION</h4>
|
|
|
|
<blockquote>
|
|
<p>The <i>kill</i>() function shall send a signal to a process or a group of processes specified by <i>pid</i>. The signal to be
|
|
sent is specified by <i>sig</i> and is either one from the list given in <a href=
|
|
"../basedefs/signal.h.html"><i><signal.h></i></a> or 0. If <i>sig</i> 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 <i>pid</i>.</p>
|
|
|
|
<p>For a process to have permission to send a signal to a process designated by <i>pid</i>, 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.</p>
|
|
|
|
<p>If <i>pid</i> is greater than 0, <i>sig</i> shall be sent to the process whose process ID is equal to <i>pid</i>.</p>
|
|
|
|
<p>If <i>pid</i> is 0, <i>sig</i> 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.</p>
|
|
|
|
<p>If <i>pid</i> is -1, <i>sig</i> shall be sent to all processes (excluding an unspecified set of system processes) for which the
|
|
process has permission to send that signal.</p>
|
|
|
|
<p>If <i>pid</i> is negative, but not -1, <i>sig</i> shall be sent to all processes (excluding an unspecified set of system
|
|
processes) whose process group ID is equal to the absolute value of <i>pid</i>, and for which the process has permission to send a
|
|
signal.</p>
|
|
|
|
<p>If the value of <i>pid</i> causes <i>sig</i> to be generated for the sending process, and if <i>sig</i> is not blocked for the
|
|
calling thread and if no other thread has <i>sig</i> unblocked or is waiting in a <a href=
|
|
"../functions/sigwait.html"><i>sigwait</i>()</a> function for <i>sig</i>, either <i>sig</i> or at least one pending unblocked
|
|
signal shall be delivered to the sending thread before <i>kill</i>() returns.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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 <i>pid</i>.</p>
|
|
|
|
<p>The <i>kill</i>() function is successful if the process has permission to send <i>sig</i> to any of the processes specified by
|
|
<i>pid</i>. If <i>kill</i>() fails, no signal shall be sent.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_323_04"></a>RETURN VALUE</h4>
|
|
|
|
<blockquote>
|
|
<p>Upon successful completion, 0 shall be returned. Otherwise, -1 shall be returned and <i>errno</i> set to indicate the error.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_323_05"></a>ERRORS</h4>
|
|
|
|
<blockquote>
|
|
<p>The <i>kill</i>() function shall fail if:</p>
|
|
|
|
<dl compact>
|
|
<dt>[EINVAL]</dt>
|
|
|
|
<dd>The value of the <i>sig</i> argument is an invalid or unsupported signal number.</dd>
|
|
|
|
<dt>[EPERM]</dt>
|
|
|
|
<dd>The process does not have permission to send the signal to any receiving process.</dd>
|
|
|
|
<dt>[ESRCH]</dt>
|
|
|
|
<dd>No process or process group can be found corresponding to that specified by <i>pid</i>.</dd>
|
|
</dl>
|
|
</blockquote>
|
|
|
|
<hr>
|
|
<div class="box"><em>The following sections are informative.</em></div>
|
|
|
|
<h4><a name="tag_03_323_06"></a>EXAMPLES</h4>
|
|
|
|
<blockquote>
|
|
<p>None.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_323_07"></a>APPLICATION USAGE</h4>
|
|
|
|
<blockquote>
|
|
<p>None.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_323_08"></a>RATIONALE</h4>
|
|
|
|
<blockquote>
|
|
<p>The semantics for permission checking for <i>kill</i>() differed between System V and most other implementations, such as
|
|
Version 7 or 4.3 BSD. The semantics chosen for this volume of IEEE Std 1003.1-2001 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.</p>
|
|
|
|
<p>Some implementations provide semantic extensions to the <i>kill</i>() function when the absolute value of <i>pid</i> is greater
|
|
than some maximum, or otherwise special, value. Negative values are a flag to <i>kill</i>(). Since most implementations return
|
|
[ESRCH] in this case, this behavior is not included in this volume of IEEE Std 1003.1-2001, although a conforming
|
|
implementation could provide such an extension.</p>
|
|
|
|
<p>The implementation-defined processes to which a signal cannot be sent may include the scheduler or <i>init</i>.</p>
|
|
|
|
<p>There was initially strong sentiment to specify that, if <i>pid</i> specifies that a signal be sent to the calling process and
|
|
that signal is not blocked, that signal would be delivered before <i>kill</i>() returns. This would permit a process to call
|
|
<i>kill</i>() and be guaranteed that the call never return. However, historical implementations that provide only the <a href=
|
|
"../functions/signal.html"><i>signal</i>()</a> function make only the weaker guarantee in this volume of
|
|
IEEE Std 1003.1-2001, because they only deliver one signal each time a process enters the kernel. Modifications to such
|
|
implementations to support the <a href="../functions/sigaction.html"><i>sigaction</i>()</a> 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 <a href="../functions/sigaction.html"><i>sigaction</i>()</a> is used, but not
|
|
necessarily when <a href="../functions/signal.html"><i>signal</i>()</a> is used. The developers of this volume of
|
|
IEEE Std 1003.1-2001 considered making the stronger requirement except when <a href=
|
|
"../functions/signal.html"><i>signal</i>()</a> 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 <a href=
|
|
"../functions/sigprocmask.html"><i>sigprocmask</i>()</a>.</p>
|
|
|
|
<p>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 <i>su</i> 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.</p>
|
|
|
|
<p>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 <i>pid</i> refers only to such
|
|
processes.</p>
|
|
|
|
<p>Existing implementations vary on the result of a <i>kill</i>() with <i>pid</i> 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 [ESRCH]. Since the definition of process lifetime in this volume of IEEE Std 1003.1-2001 covers
|
|
inactive processes, the [ESRCH] 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 <i>kill</i>(). (Usually this is done with the null
|
|
signal; this can be done reliably with <a href="../functions/waitpid.html"><i>waitpid</i>()</a>.)</p>
|
|
|
|
<p>There is some belief that the name <i>kill</i>() 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.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_323_09"></a>FUTURE DIRECTIONS</h4>
|
|
|
|
<blockquote>
|
|
<p>None.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_323_10"></a>SEE ALSO</h4>
|
|
|
|
<blockquote>
|
|
<p><a href="getpid.html"><i>getpid</i>()</a> , <a href="raise.html"><i>raise</i>()</a> , <a href="setsid.html"><i>setsid</i>()</a>
|
|
, <a href="sigaction.html"><i>sigaction</i>()</a> , <a href="sigqueue.html"><i>sigqueue</i>()</a> , the Base Definitions volume of
|
|
IEEE Std 1003.1-2001, <a href="../basedefs/signal.h.html"><i><signal.h></i></a>, <a href=
|
|
"../basedefs/sys/types.h.html"><i><sys/types.h></i></a></p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_323_11"></a>CHANGE HISTORY</h4>
|
|
|
|
<blockquote>
|
|
<p>First released in Issue 1. Derived from Issue 1 of the SVID.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_323_12"></a>Issue 5</h4>
|
|
|
|
<blockquote>
|
|
<p>The DESCRIPTION is updated for alignment with the POSIX Threads Extension.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_323_13"></a>Issue 6</h4>
|
|
|
|
<blockquote>
|
|
<p>In the SYNOPSIS, the optional include of the <a href="../basedefs/sys/types.h.html"><i><sys/types.h></i></a> header is
|
|
removed.</p>
|
|
|
|
<p>The following new requirements on POSIX implementations derive from alignment with the Single UNIX Specification:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>In the DESCRIPTION, the second paragraph is reworded to indicate that the saved set-user-ID of the calling process is checked in
|
|
place of its effective user ID. This is a FIPS requirement.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The requirement to include <a href="../basedefs/sys/types.h.html"><i><sys/types.h></i></a> has been removed. Although <a
|
|
href="../basedefs/sys/types.h.html"><i><sys/types.h></i></a> was required for conforming implementations of previous POSIX
|
|
specifications, it was not required for UNIX applications.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>The behavior when <i>pid</i> is -1 is now specified. It was previously explicitly unspecified in the POSIX.1-1988 standard.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The DESCRIPTION is updated to avoid use of the term "must" for application requirements.</p>
|
|
</blockquote>
|
|
|
|
<div class="box"><em>End of informative text.</em></div>
|
|
|
|
<hr>
|
|
<hr size="2" noshade>
|
|
<center><font size="2"><!--footer start-->
|
|
UNIX ® is a registered Trademark of The Open Group.<br>
|
|
POSIX ® is a registered Trademark of The IEEE.<br>
|
|
[ <a href="../mindex.html">Main Index</a> | <a href="../basedefs/contents.html">XBD</a> | <a href=
|
|
"../utilities/contents.html">XCU</a> | <a href="../functions/contents.html">XSH</a> | <a href="../xrat/contents.html">XRAT</a>
|
|
]</font></center>
|
|
|
|
<!--footer end-->
|
|
<hr size="2" noshade>
|
|
</body>
|
|
</html>
|
|
|