logo

oasis-root

Compiled tree of Oasis Linux based on own branch at <https://hacktivis.me/git/oasis/> git clone https://anongit.hacktivis.me/git/oasis-root.git

kill.3p (9427B)


  1. '\" et
  2. .TH KILL "3P" 2017 "IEEE/The Open Group" "POSIX Programmer's Manual"
  3. .\"
  4. .SH PROLOG
  5. This manual page is part of the POSIX Programmer's Manual.
  6. The Linux implementation of this interface may differ (consult
  7. the corresponding Linux manual page for details of Linux behavior),
  8. or the interface may not be implemented on Linux.
  9. .\"
  10. .SH NAME
  11. kill
  12. \(em send a signal to a process or a group of processes
  13. .SH SYNOPSIS
  14. .LP
  15. .nf
  16. #include <signal.h>
  17. .P
  18. int kill(pid_t \fIpid\fP, int \fIsig\fP);
  19. .fi
  20. .SH DESCRIPTION
  21. The
  22. \fIkill\fR()
  23. function shall send a signal to a process or a group of processes
  24. specified by
  25. .IR pid .
  26. The signal to be sent is specified by
  27. .IR sig
  28. and is either one from the list given in
  29. .IR <signal.h>
  30. or 0. If
  31. .IR sig
  32. is 0 (the null signal), error checking is performed but no signal is
  33. actually sent. The null signal can be used to check the validity of
  34. .IR pid .
  35. .P
  36. For a process to have permission to send a signal to a process
  37. designated by
  38. .IR pid ,
  39. unless the sending process has appropriate privileges, the real or
  40. effective user ID of the sending process shall match the real or saved
  41. set-user-ID of the receiving process.
  42. .P
  43. If
  44. .IR pid
  45. is greater than 0,
  46. .IR sig
  47. shall be sent to the process whose process ID is equal to
  48. .IR pid .
  49. .P
  50. If
  51. .IR pid
  52. is 0,
  53. .IR sig
  54. shall be sent to all processes (excluding an unspecified set of system
  55. processes) whose process group ID is equal to the process group ID of
  56. the sender, and for which the process has permission to send a signal.
  57. .P
  58. If
  59. .IR pid
  60. is \-1,
  61. .IR sig
  62. shall be sent to all processes (excluding an unspecified set of system
  63. processes) for which the process has permission to send that signal.
  64. .P
  65. If
  66. .IR pid
  67. is negative, but not \-1,
  68. .IR sig
  69. shall be sent to all processes (excluding an unspecified set of system
  70. processes) whose process group ID is equal to the absolute value of
  71. .IR pid ,
  72. and for which the process has permission to send a signal.
  73. .P
  74. If the value of
  75. .IR pid
  76. causes
  77. .IR sig
  78. to be generated for the sending process, and if
  79. .IR sig
  80. is not blocked for the calling thread and if no other thread has
  81. .IR sig
  82. unblocked or is waiting in a
  83. \fIsigwait\fR()
  84. function for
  85. .IR sig ,
  86. either
  87. .IR sig
  88. or at least one pending unblocked signal shall be delivered to the
  89. sending thread before
  90. \fIkill\fR()
  91. returns.
  92. .P
  93. The user ID tests described above shall not be applied when sending
  94. SIGCONT to a process that is a member of the same session as the
  95. sending process.
  96. .P
  97. An implementation that provides extended security controls may impose
  98. further implementation-defined restrictions on the sending of
  99. signals, including the null signal. In particular, the system may deny
  100. the existence of some or all of the processes specified by
  101. .IR pid .
  102. .P
  103. The
  104. \fIkill\fR()
  105. function is successful if the process has permission to send
  106. .IR sig
  107. to any of the processes specified by
  108. .IR pid .
  109. If
  110. \fIkill\fR()
  111. fails, no signal shall be sent.
  112. .SH "RETURN VALUE"
  113. Upon successful completion, 0 shall be returned. Otherwise, \-1
  114. shall be returned and
  115. .IR errno
  116. set to indicate the error.
  117. .SH ERRORS
  118. The
  119. \fIkill\fR()
  120. function shall fail if:
  121. .TP
  122. .BR EINVAL
  123. The value of the
  124. .IR sig
  125. argument is an invalid or unsupported signal number.
  126. .TP
  127. .BR EPERM
  128. The process does not have permission to send the signal to any
  129. receiving process.
  130. .TP
  131. .BR ESRCH
  132. No process or process group can be found corresponding to that
  133. specified by
  134. .IR pid .
  135. .LP
  136. .IR "The following sections are informative."
  137. .SH EXAMPLES
  138. None.
  139. .SH "APPLICATION USAGE"
  140. None.
  141. .SH RATIONALE
  142. The semantics for permission checking for
  143. \fIkill\fR()
  144. differed between System V and most other implementations, such as
  145. Version 7 or
  146. 4.3 BSD. The semantics chosen for this volume of POSIX.1\(hy2017 agree with System V.
  147. Specifically, a set-user-ID
  148. process cannot protect itself against signals (or at least not against
  149. SIGKILL)
  150. unless it changes its real user ID.
  151. This choice allows the user who starts an application to send it
  152. signals even if it changes its effective user ID.
  153. The other semantics give more power to an application that wants to
  154. protect itself from the user who ran it.
  155. .P
  156. Some implementations provide semantic extensions to the
  157. \fIkill\fR()
  158. function when the absolute value of
  159. .IR pid
  160. is greater than some maximum, or otherwise special, value. Negative
  161. values are a flag to
  162. \fIkill\fR().
  163. Since most implementations return
  164. .BR [ESRCH]
  165. in this case, this behavior is not included in this volume of POSIX.1\(hy2017, although
  166. a conforming implementation could provide such an extension.
  167. .P
  168. The unspecified processes to which a signal cannot be sent
  169. may include the scheduler or
  170. .IR init .
  171. .P
  172. There was initially strong sentiment to specify that, if
  173. .IR pid
  174. specifies that a signal be sent to the calling process and that signal
  175. is not blocked, that signal would be delivered before
  176. \fIkill\fR()
  177. returns. This would permit a process to call
  178. \fIkill\fR()
  179. and be guaranteed that the call never return. However, historical
  180. implementations that provide only the
  181. \fIsignal\fR()
  182. function make only the weaker guarantee in this volume of POSIX.1\(hy2017, because they
  183. only deliver one signal each time a process enters the kernel.
  184. Modifications to such implementations to support the
  185. \fIsigaction\fR()
  186. function generally require entry to the kernel following return from a
  187. signal-catching function, in order to restore the signal mask. Such
  188. modifications have the effect of satisfying the stronger requirement,
  189. at least when
  190. \fIsigaction\fR()
  191. is used, but not necessarily when
  192. \fIsignal\fR()
  193. is used. The standard developers considered making the
  194. stronger requirement except when
  195. \fIsignal\fR()
  196. is used, but felt this would be unnecessarily complex. Implementors
  197. are encouraged to meet the stronger requirement whenever possible. In
  198. practice, the weaker requirement is the same, except in the rare case
  199. when two signals arrive during a very short window. This reasoning
  200. also applies to a similar requirement for
  201. \fIsigprocmask\fR().
  202. .P
  203. In 4.2 BSD, the SIGCONT
  204. signal can be sent to any descendant process regardless of user-ID
  205. security checks.
  206. This allows a job control shell to continue a job even if processes in
  207. the
  208. job have altered their user IDs (as in the
  209. .IR su
  210. command). In keeping with the addition of the concept of sessions,
  211. similar functionality is provided by allowing the SIGCONT
  212. signal to be sent to any process in the same session regardless of user
  213. ID security checks. This is less restrictive than BSD in the sense
  214. that ancestor processes (in the same session) can now be the recipient.
  215. It is more restrictive than BSD in the sense that descendant processes
  216. that form new sessions are now subject to the user ID checks. A similar
  217. relaxation of security is not necessary for the other job control
  218. signals since those signals are typically sent by the terminal driver
  219. in recognition of special characters being typed; the terminal driver
  220. bypasses all security checks.
  221. .P
  222. In secure implementations, a process may be restricted
  223. from sending a signal to a process having a different security label.
  224. In order to prevent the existence or nonexistence of a process from
  225. being used as a covert channel,
  226. such processes should appear nonexistent to the sender; that is,
  227. .BR [ESRCH]
  228. should be returned, rather than
  229. .BR [EPERM] ,
  230. if
  231. .IR pid
  232. refers only to such processes.
  233. .P
  234. Historical implementations varied on the result of a
  235. \fIkill\fR()
  236. with
  237. .IR pid
  238. indicating a zombie process. Some indicated success on such a call
  239. (subject to permission checking), while others gave an error of
  240. .BR [ESRCH] .
  241. Since the definition of process lifetime in this volume of POSIX.1\(hy2017
  242. covers zombie processes, the
  243. .BR [ESRCH]
  244. error as described is inappropriate in this case and implementations
  245. that give this error do not conform. This means that an application
  246. cannot have a parent process check for termination of a particular
  247. child by sending it the null signal with
  248. \fIkill\fR(),
  249. but must instead use
  250. \fIwaitpid\fR()
  251. or
  252. \fIwaitid\fR().
  253. .P
  254. There is some belief that the name
  255. \fIkill\fR()
  256. is misleading, since the function is not always intended to cause
  257. process termination. However, the name is common to all historical
  258. implementations, and any change would be in conflict with the goal of
  259. minimal changes to existing application code.
  260. .SH "FUTURE DIRECTIONS"
  261. None.
  262. .SH "SEE ALSO"
  263. .IR "\fIgetpid\fR\^(\|)",
  264. .IR "\fIraise\fR\^(\|)",
  265. .IR "\fIsetsid\fR\^(\|)",
  266. .IR "\fIsigaction\fR\^(\|)",
  267. .IR "\fIsigqueue\fR\^(\|)",
  268. .IR "\fIwait\fR\^(\|)"
  269. .P
  270. The Base Definitions volume of POSIX.1\(hy2017,
  271. .IR "\fB<signal.h>\fP",
  272. .IR "\fB<sys_types.h>\fP"
  273. .\"
  274. .SH COPYRIGHT
  275. Portions of this text are reprinted and reproduced in electronic form
  276. from IEEE Std 1003.1-2017, Standard for Information Technology
  277. -- Portable Operating System Interface (POSIX), The Open Group Base
  278. Specifications Issue 7, 2018 Edition,
  279. Copyright (C) 2018 by the Institute of
  280. Electrical and Electronics Engineers, Inc and The Open Group.
  281. In the event of any discrepancy between this version and the original IEEE and
  282. The Open Group Standard, the original IEEE and The Open Group Standard
  283. is the referee document. The original Standard can be obtained online at
  284. http://www.opengroup.org/unix/online.html .
  285. .PP
  286. Any typographical or formatting errors that appear
  287. in this page are most likely
  288. to have been introduced during the conversion of the source files to
  289. man page format. To report such errors, see
  290. https://www.kernel.org/doc/man-pages/reporting_bugs.html .