📄 kill.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-2003 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, 2003 Edition<br>Copyright © 2001-2003 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 besent 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 butno 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 hasappropriate privileges, the real or effective user ID of the sending process shall match the real or saved set-user-ID of thereceiving 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 processgroup 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 theprocess 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 systemprocesses) whose process group ID is equal to the absolute value of <i>pid</i>, and for which the process has permission to send asignal.</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 thecalling 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 unblockedsignal 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 asthe sending process.</p><p>An implementation that provides extended security controls may impose further implementation-defined restrictions on the sendingof signals, including the null signal. In particular, the system may deny the existence of some or all of the processes specifiedby <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 asVersion 7 or 4.3 BSD. The semantics chosen for this volume of IEEE Std 1003.1-2001 agree with System V. Specifically, aset-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 othersemantics 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 greaterthan 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 conformingimplementation 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 andthat 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 ofIEEE Std 1003.1-2001, because they only deliver one signal each time a process enters the kernel. Modifications to suchimplementations to support the <a href="../functions/sigaction.html"><i>sigaction</i>()</a> function generally require entry to thekernel following return from a signal-catching function, in order to restore the signal mask. Such modifications have the effect ofsatisfying the stronger requirement, at least when <a href="../functions/sigaction.html"><i>sigaction</i>()</a> is used, but notnecessarily when <a href="../functions/signal.html"><i>signal</i>()</a> is used. The developers of this volume ofIEEE 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 encouragedto meet the stronger requirement whenever possible. In practice, the weaker requirement is the same, except in the rare case whentwo 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 jobcontrol shell to continue a job even if processes in the job have altered their user IDs (as in the <i>su</i> command). In keepingwith the addition of the concept of sessions, similar functionality is provided by allowing the SIGCONT signal to be sent to anyprocess in the same session regardless of user ID security checks. This is less restrictive than BSD in the sense that ancestorprocesses (in the same session) can now be the recipient. It is more restrictive than BSD in the sense that descendant processesthat form new sessions are now subject to the user ID checks. A similar relaxation of security is not necessary for the other jobcontrol signals since those signals are typically sent by the terminal driver in recognition of special characters being typed; theterminal 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. Inorder to prevent the existence or nonexistence of a process from being used as a covert channel, such processes should appearnonexistent to the sender; that is, [ESRCH] should be returned, rather than [EPERM], if <i>pid</i> refers only to suchprocesses.</p><p>Existing implementations vary on the result of a <i>kill</i>() with <i>pid</i> indicating an inactive process (a terminatedprocess that has not been waited for by its parent). Some indicate success on such a call (subject to permission checking), whileothers give an error of [ESRCH]. Since the definition of process lifetime in this volume of IEEE Std 1003.1-2001 coversinactive processes, the [ESRCH] error as described is inappropriate in this case. In particular, this means that an applicationcannot have a parent process check for termination of a particular child with <i>kill</i>(). (Usually this is done with the nullsignal; 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 processtermination. However, the name is common to all historical implementations, and any change would be in conflict with the goal ofminimal 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 ofIEEE 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 isremoved.</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 inplace 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 <ahref="../basedefs/sys/types.h.html"><i><sys/types.h></i></a> was required for conforming implementations of previous POSIXspecifications, 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>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -