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

sigaction.3p (20097B)


  1. '\" et
  2. .TH SIGACTION "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. sigaction
  12. \(em examine and change a signal action
  13. .SH SYNOPSIS
  14. .LP
  15. .nf
  16. #include <signal.h>
  17. .P
  18. int sigaction(int \fIsig\fP, const struct sigaction *restrict \fIact\fP,
  19. struct sigaction *restrict \fIoact\fP);
  20. .fi
  21. .SH DESCRIPTION
  22. The
  23. \fIsigaction\fR()
  24. function allows the calling process to examine and/or specify the
  25. action to be associated with a specific signal. The argument
  26. .IR sig
  27. specifies the signal; acceptable values are defined in
  28. .IR <signal.h> .
  29. .P
  30. The structure
  31. .BR sigaction ,
  32. used to describe an action to be taken, is defined in the
  33. .IR <signal.h>
  34. header to include at least the following members:
  35. .ad l
  36. .TS
  37. center box tab(!);
  38. cB | cB | cB
  39. lw(1.5i)B | lw(1.25i)I | lw(2.5i).
  40. Member Type!Member Name!Description
  41. _
  42. void(*) (int)!sa_handler!T{
  43. Pointer to a signal-catching function or one of the macros
  44. SIG_IGN or SIG_DFL.
  45. T}
  46. sigset_t!sa_mask!T{
  47. Additional set of signals to be blocked during execution of
  48. signal-catching function.
  49. T}
  50. int!sa_flags!T{
  51. Special flags to affect behavior of signal.
  52. T}
  53. T{
  54. void(*) (int,
  55. .br
  56. \0\0siginfo_t *, void *)
  57. T}!sa_sigaction!Pointer to a signal-catching function.
  58. .TE
  59. .ad b
  60. .P
  61. The storage occupied by
  62. .IR sa_handler
  63. and
  64. .IR sa_sigaction
  65. may overlap, and a conforming application shall not use both
  66. simultaneously.
  67. .P
  68. If the argument
  69. .IR act
  70. is not a null pointer, it points to a structure specifying the action
  71. to be associated with the specified signal. If the argument
  72. .IR oact
  73. is not a null pointer, the action previously associated with the signal
  74. is stored in the location pointed to by the argument
  75. .IR oact .
  76. If the argument
  77. .IR act
  78. is a null pointer, signal handling is unchanged; thus, the call can be
  79. used to enquire about the current handling of a given signal. The
  80. SIGKILL and SIGSTOP signals shall not be added to the signal
  81. mask using this mechanism; this restriction shall be enforced by the
  82. system without causing an error to be indicated.
  83. .P
  84. If the SA_SIGINFO flag (see below) is cleared in the
  85. .IR sa_flags
  86. field of the
  87. .BR sigaction
  88. structure, the
  89. .IR sa_handler
  90. field identifies the action to be associated with the specified signal.
  91. If the SA_SIGINFO flag is set in the
  92. .IR sa_flags
  93. field, the
  94. .IR sa_sigaction
  95. field specifies a signal-catching function.
  96. .P
  97. The
  98. .IR sa_flags
  99. field can be used to modify the behavior of the specified signal.
  100. .P
  101. The following flags, defined in the
  102. .IR <signal.h>
  103. header, can be set in
  104. .IR sa_flags :
  105. .IP SA_NOCLDSTOP 14
  106. Do not generate SIGCHLD when children stop
  107. or stopped children continue.
  108. .RS 14
  109. .P
  110. If
  111. .IR sig
  112. is SIGCHLD and the SA_NOCLDSTOP flag is not set in
  113. .IR sa_flags ,
  114. and the implementation supports the SIGCHLD signal, then a SIGCHLD
  115. signal shall be generated for the calling process whenever any of its
  116. child processes stop
  117. and a SIGCHLD signal may be generated for the calling
  118. process whenever any of its stopped child processes are continued.
  119. If
  120. .IR sig
  121. is SIGCHLD and the SA_NOCLDSTOP flag is set in
  122. .IR sa_flags ,
  123. then the implementation shall not generate a SIGCHLD signal in this
  124. way.
  125. .RE
  126. .IP SA_ONSTACK 14
  127. If set and an alternate signal stack has been declared with
  128. \fIsigaltstack\fR(),
  129. the signal shall be delivered to the calling process on that stack.
  130. Otherwise, the signal shall be delivered on the current stack.
  131. .IP SA_RESETHAND 14
  132. If set, the disposition of the signal shall be reset to SIG_DFL and the
  133. SA_SIGINFO flag shall be cleared on entry to the signal handler.
  134. .RS 14
  135. .TP 10
  136. .BR Note:
  137. SIGILL and SIGTRAP cannot be automatically reset when delivered; the
  138. system silently enforces this restriction.
  139. .P
  140. Otherwise, the disposition of the signal shall not be modified on entry
  141. to the signal handler.
  142. .P
  143. In addition, if this flag is set,
  144. \fIsigaction\fR()
  145. may behave as if the SA_NODEFER flag were also set.
  146. .RE
  147. .IP SA_RESTART 14
  148. This flag affects the behavior of interruptible functions; that is,
  149. those specified to fail with
  150. .IR errno
  151. set to
  152. .BR [EINTR] .
  153. If set, and a function specified as interruptible is interrupted by
  154. this signal, the function shall restart and shall not fail with
  155. .BR [EINTR]
  156. unless otherwise specified. If an interruptible function which uses a
  157. timeout is restarted, the duration of the timeout following the restart
  158. is set to an unspecified value that does not exceed the original
  159. timeout value. If the flag is not set, interruptible functions
  160. interrupted by this signal shall fail with
  161. .IR errno
  162. set to
  163. .BR [EINTR] .
  164. .IP SA_SIGINFO 14
  165. If cleared and the signal is caught, the signal-catching function
  166. shall be entered as:
  167. .RS 14
  168. .sp
  169. .RS 4
  170. .nf
  171. void func(int \fIsigno\fP);
  172. .fi
  173. .P
  174. .RE
  175. .P
  176. where
  177. .IR signo
  178. is the only argument to the signal-catching function. In this case, the
  179. application shall use the
  180. .IR sa_handler
  181. member to describe the signal-catching function and the application
  182. shall not modify the
  183. .IR sa_sigaction
  184. member.
  185. .P
  186. If SA_SIGINFO is set and the signal is caught, the signal-catching
  187. function shall be entered as:
  188. .sp
  189. .RS 4
  190. .nf
  191. void func(int \fIsigno\fP, siginfo_t *\fIinfo\fP, void *\fIcontext\fP);
  192. .fi
  193. .P
  194. .RE
  195. .P
  196. where two additional arguments are passed to the signal-catching
  197. function. The second argument shall point to an object of type
  198. .BR siginfo_t
  199. explaining the reason why the signal was generated; the third argument
  200. can be cast to a pointer to an object of type
  201. .BR ucontext_t
  202. to refer to the receiving thread's context that was interrupted when
  203. the signal was delivered. In this case, the application shall use the
  204. .IR sa_sigaction
  205. member to describe the signal-catching function and the application
  206. shall not modify the
  207. .IR sa_handler
  208. member.
  209. .P
  210. The
  211. .IR si_signo
  212. member contains the system-generated signal number.
  213. .P
  214. The
  215. .IR si_errno
  216. member may contain implementation-defined additional error
  217. information; if non-zero, it contains an error number identifying the
  218. condition that caused the signal to be generated.
  219. .P
  220. The
  221. .IR si_code
  222. member contains a code identifying the cause of the signal, as
  223. described in
  224. .IR "Section 2.4.3" ", " "Signal Actions".
  225. .RE
  226. .IP SA_NOCLDWAIT 14
  227. If
  228. .IR sig
  229. does not equal SIGCHLD, the behavior is unspecified. Otherwise, the
  230. behavior of the SA_NOCLDWAIT flag is as specified in
  231. .IR "Consequences of Process Termination".
  232. .IP SA_NODEFER 14
  233. If set and
  234. .IR sig
  235. is caught,
  236. .IR sig
  237. shall not be added to the thread's signal mask on entry to the signal
  238. handler unless it is included in
  239. .IR sa_mask .
  240. Otherwise,
  241. .IR sig
  242. shall always be added to the thread's signal mask on entry to the
  243. signal handler.
  244. .P
  245. When a signal is caught by a signal-catching function installed by
  246. \fIsigaction\fR(),
  247. a new signal mask is calculated and installed for the duration of the
  248. signal-catching function (or until a call to either
  249. \fIsigprocmask\fR()
  250. or
  251. \fIsigsuspend\fR()
  252. is made). This mask is formed by taking the union of the current
  253. signal mask and the value of the
  254. .IR sa_mask
  255. for the signal being delivered, and unless SA_NODEFER or
  256. SA_RESETHAND is set,
  257. then including the signal being delivered. If and when the user's
  258. signal handler returns normally, the original signal mask is restored.
  259. .P
  260. Once an action is installed for a specific signal, it shall remain
  261. installed until another action is explicitly requested (by another
  262. call to
  263. \fIsigaction\fR()),
  264. until the SA_RESETHAND flag causes resetting of the handler,
  265. or until one of the
  266. .IR exec
  267. functions is called.
  268. .P
  269. If the previous action for
  270. .IR sig
  271. had been established by
  272. \fIsignal\fR(),
  273. the values of the fields returned in the structure pointed to by
  274. .IR oact
  275. are unspecified, and in particular
  276. .IR oact ->\c
  277. .IR sa_handler
  278. is not necessarily the same value passed to
  279. \fIsignal\fR().
  280. However, if a pointer to the same structure or a copy thereof is passed
  281. to a subsequent call to
  282. \fIsigaction\fR()
  283. via the
  284. .IR act
  285. argument, handling of the signal shall be as if the original call to
  286. \fIsignal\fR()
  287. were repeated.
  288. .P
  289. If
  290. \fIsigaction\fR()
  291. fails, no new signal handler is installed.
  292. .P
  293. It is unspecified whether an attempt to set the action for a signal
  294. that cannot be caught or ignored to SIG_DFL is ignored or causes an
  295. error to be returned with
  296. .IR errno
  297. set to
  298. .BR [EINVAL] .
  299. .P
  300. If SA_SIGINFO is not set in
  301. .IR sa_flags ,
  302. then the disposition of subsequent occurrences of
  303. .IR sig
  304. when it is already pending is implementation-defined; the
  305. signal-catching function shall be invoked with a single argument.
  306. If SA_SIGINFO is set in
  307. .IR sa_flags ,
  308. then subsequent occurrences of
  309. .IR sig
  310. generated by
  311. \fIsigqueue\fR()
  312. or as a result of any signal-generating function that supports the
  313. specification of an application-defined value (when
  314. .IR sig
  315. is already pending) shall be queued in FIFO order until delivered or
  316. accepted; the signal-catching function shall be invoked with three
  317. arguments. The application specified value is passed to the
  318. signal-catching function as the
  319. .IR si_value
  320. member of the
  321. .BR siginfo_t
  322. structure.
  323. .P
  324. The result of the use of
  325. \fIsigaction\fR()
  326. and a
  327. \fIsigwait\fR()
  328. function concurrently within a process on the same signal is
  329. unspecified.
  330. .SH "RETURN VALUE"
  331. Upon successful completion,
  332. \fIsigaction\fR()
  333. shall return 0; otherwise, \-1 shall be returned,
  334. .IR errno
  335. shall be set to indicate the error, and no new signal-catching function
  336. shall be installed.
  337. .br
  338. .SH ERRORS
  339. The
  340. \fIsigaction\fR()
  341. function shall fail if:
  342. .TP
  343. .BR EINVAL
  344. The
  345. .IR sig
  346. argument is not a valid signal number or an attempt is made to catch a
  347. signal that cannot be caught or ignore a signal that cannot be ignored.
  348. .P
  349. The
  350. \fIsigaction\fR()
  351. function may fail if:
  352. .TP
  353. .BR EINVAL
  354. An attempt was made to set the action to SIG_DFL for a signal that
  355. cannot be caught or ignored (or both).
  356. .P
  357. In addition, on systems that do not support the XSI option, the
  358. \fIsigaction\fR()
  359. function may fail if the SA_SIGINFO flag is set in the
  360. .IR sa_flags
  361. field of the
  362. .BR sigaction
  363. structure for a signal not in the range SIGRTMIN to SIGRTMAX.
  364. .LP
  365. .IR "The following sections are informative."
  366. .SH EXAMPLES
  367. .SS "Establishing a Signal Handler"
  368. .P
  369. The following example demonstrates the use of
  370. \fIsigaction\fR()
  371. to establish a handler for the SIGINT signal.
  372. .sp
  373. .RS 4
  374. .nf
  375. #include <signal.h>
  376. .P
  377. static void handler(int signum)
  378. {
  379. /* Take appropriate actions for signal delivery */
  380. }
  381. .P
  382. int main()
  383. {
  384. struct sigaction sa;
  385. .P
  386. sa.sa_handler = handler;
  387. sigemptyset(&sa.sa_mask);
  388. sa.sa_flags = SA_RESTART; /* Restart functions if
  389. interrupted by handler */
  390. if (sigaction(SIGINT, &sa, NULL) == -1)
  391. /* Handle error */;
  392. .P
  393. /* Further code */
  394. }
  395. .fi
  396. .P
  397. .RE
  398. .SH "APPLICATION USAGE"
  399. The
  400. \fIsigaction\fR()
  401. function supersedes the
  402. \fIsignal\fR()
  403. function, and should be used in preference. In particular,
  404. \fIsigaction\fR()
  405. and
  406. \fIsignal\fR()
  407. should not be used in the same process to control the same signal.
  408. The behavior of async-signal-safe functions, as defined in their
  409. respective DESCRIPTION sections, is as specified by this volume of POSIX.1\(hy2017, regardless
  410. of invocation from a signal-catching function. This is the only intended
  411. meaning of the statement that async-signal-safe functions may be used in
  412. signal-catching functions without restrictions. Applications must still
  413. consider all effects of such functions on such things as data structures,
  414. files, and process state. In particular, application developers need
  415. to consider the restrictions on interactions when interrupting
  416. \fIsleep\fR()
  417. and interactions among multiple handles for a file description. The
  418. fact that any specific function is listed as async-signal-safe does not
  419. necessarily mean that invocation of that function from a
  420. signal-catching function is recommended.
  421. .P
  422. In order to prevent errors arising from interrupting non-async-signal-safe
  423. function calls, applications should protect calls to these functions
  424. either by blocking the appropriate signals or through the use of some
  425. programmatic semaphore (see
  426. .IR "\fIsemget\fR\^(\|)",
  427. .IR "\fIsem_init\fR\^(\|)",
  428. .IR "\fIsem_open\fR\^(\|)",
  429. and so on). Note in particular that even the ``safe'' functions may
  430. modify
  431. .IR errno ;
  432. the signal-catching function, if not executing as an independent
  433. thread, should save and restore its value in order to avoid the
  434. possibility that delivery of a signal in between an error return
  435. from a function that sets
  436. .IR errno
  437. and the subsequent examination of
  438. .IR errno
  439. could result in the signal-catching function changing the value of
  440. .IR errno .
  441. Naturally, the same principles apply to the async-signal-safety of
  442. application routines and asynchronous data access. Note that
  443. \fIlongjmp\fR()
  444. and
  445. \fIsiglongjmp\fR()
  446. are not in the list of async-signal-safe functions. This is because
  447. the code executing after
  448. \fIlongjmp\fR()
  449. and
  450. \fIsiglongjmp\fR()
  451. can call any unsafe functions with the same danger as calling those
  452. unsafe functions directly from the signal handler. Applications that
  453. use
  454. \fIlongjmp\fR()
  455. and
  456. \fIsiglongjmp\fR()
  457. from within signal handlers require rigorous protection in order to be
  458. portable. Many of the other functions that are excluded from the list
  459. are traditionally implemented using either
  460. \fImalloc\fR()
  461. or
  462. \fIfree\fR()
  463. functions or the standard I/O library, both of which traditionally
  464. use data structures in a non-async-signal-safe manner. Since any
  465. combination of different functions using a common data structure can
  466. cause async-signal-safety problems, this volume of POSIX.1\(hy2017 does not define the behavior
  467. when any unsafe function is called in a signal handler that interrupts
  468. an unsafe function.
  469. .P
  470. Usually, the signal is executed on the stack that was in effect before
  471. the signal was delivered. An alternate stack may be specified to
  472. receive a subset of the signals being caught.
  473. .P
  474. When the signal handler returns, the receiving thread resumes
  475. execution at the point it was interrupted unless the signal handler
  476. makes other arrangements. If
  477. \fIlongjmp\fR()
  478. or
  479. \fI_longjmp\fR()
  480. is used to leave the signal handler, then the signal mask must be
  481. explicitly restored.
  482. .P
  483. This volume of POSIX.1\(hy2017 defines the third argument of a signal handling function when
  484. SA_SIGINFO is set as a
  485. .BR "void *"
  486. instead of a
  487. .BR "ucontext_t *" ,
  488. but without requiring type checking. New applications should
  489. explicitly cast the third argument of the signal handling function to
  490. .BR "ucontext_t *" .
  491. .P
  492. The BSD optional four argument signal handling function is not
  493. supported by this volume of POSIX.1\(hy2017. The BSD declaration would be:
  494. .sp
  495. .RS 4
  496. .nf
  497. void handler(int \fIsig\fP, int \fIcode\fP, struct sigcontext *\fIscp\fP,
  498. char *\fIaddr\fP);
  499. .fi
  500. .P
  501. .RE
  502. .P
  503. where
  504. .IR sig
  505. is the signal number,
  506. .IR code
  507. is additional information on certain signals,
  508. .IR scp
  509. is a pointer to the
  510. .BR sigcontext
  511. structure, and
  512. .IR addr
  513. is additional address information. Much the same information is
  514. available in the objects pointed to by the second argument of the
  515. signal handler specified when SA_SIGINFO is set.
  516. .P
  517. Since the
  518. \fIsigaction\fR()
  519. function is allowed but not required to set SA_NODEFER when the
  520. application sets the SA_RESETHAND flag, applications which depend on the
  521. SA_RESETHAND functionality for the newly installed signal handler must
  522. always explicitly set SA_NODEFER when they set SA_RESETHAND in order to
  523. be portable.
  524. .P
  525. See also the rationale for Realtime Signal Generation and Delivery in
  526. the Rationale (Informative) volume of POSIX.1\(hy2017,
  527. .IR "Section B.2.4.2" ", " "Signal Generation and Delivery".
  528. .SH RATIONALE
  529. Although this volume of POSIX.1\(hy2017 requires that signals that cannot be ignored
  530. shall not be added to the signal mask when a signal-catching function
  531. is entered, there is no explicit requirement that subsequent calls to
  532. \fIsigaction\fR()
  533. reflect this in the information returned in the
  534. .IR oact
  535. argument. In other words, if SIGKILL
  536. is included in the
  537. .IR sa_mask
  538. field of
  539. .IR act ,
  540. it is unspecified whether or not a subsequent call to
  541. \fIsigaction\fR()
  542. returns with SIGKILL included in the
  543. .IR sa_mask
  544. field of
  545. .IR oact .
  546. .P
  547. The SA_NOCLDSTOP
  548. flag, when supplied in the
  549. .IR act ->\c
  550. .IR sa_flags
  551. parameter, allows overloading SIGCHLD with the System V
  552. semantics that each SIGCLD
  553. signal indicates a single terminated child. Most conforming applications
  554. that catch SIGCHLD are expected to install signal-catching functions
  555. that repeatedly call the
  556. \fIwaitpid\fR()
  557. function with the WNOHANG
  558. flag set, acting on each child for which status is returned, until
  559. \fIwaitpid\fR()
  560. returns zero. If stopped children are not of interest, the use of the
  561. SA_NOCLDSTOP
  562. flag can prevent the overhead from invoking the signal-catching routine
  563. when they stop.
  564. .P
  565. Some historical implementations also define other mechanisms for
  566. stopping processes, such as the
  567. \fIptrace\fR()
  568. function. These implementations usually do not generate a SIGCHLD
  569. signal when processes stop due to this mechanism; however, that is
  570. beyond the scope of this volume of POSIX.1\(hy2017.
  571. .P
  572. This volume of POSIX.1\(hy2017 requires that calls to
  573. \fIsigaction\fR()
  574. that supply a NULL
  575. .IR act
  576. argument succeed, even in the case of signals that cannot be caught or
  577. ignored (that is, SIGKILL
  578. or SIGSTOP).
  579. The System V
  580. \fIsignal\fR()
  581. and BSD
  582. \fIsigvec\fR()
  583. functions return
  584. .BR [EINVAL]
  585. in these cases and, in this respect, their behavior varies from
  586. \fIsigaction\fR().
  587. .P
  588. This volume of POSIX.1\(hy2017 requires that
  589. \fIsigaction\fR()
  590. properly save and restore a signal action set up by the ISO\ C standard
  591. \fIsignal\fR()
  592. function. However, there is no guarantee that the reverse is true, nor
  593. could there be given the greater amount of information conveyed by the
  594. .BR sigaction
  595. structure. Because of this, applications should avoid using both
  596. functions for the same signal in the same process. Since this cannot
  597. always be avoided in case of general-purpose library routines, they
  598. should always be implemented with
  599. \fIsigaction\fR().
  600. .P
  601. It was intended that the
  602. \fIsignal\fR()
  603. function should be implementable as a library routine using
  604. \fIsigaction\fR().
  605. .P
  606. The POSIX Realtime Extension extends the
  607. \fIsigaction\fR()
  608. function as specified by the POSIX.1\(hy1990 standard to allow the application to request
  609. on a per-signal basis via an additional signal action flag that the
  610. extra parameters, including the application-defined signal value, if
  611. any, be passed to the signal-catching function.
  612. .SH "FUTURE DIRECTIONS"
  613. None.
  614. .SH "SEE ALSO"
  615. .IR "Section 2.4" ", " "Signal Concepts",
  616. .IR "\fIexec\fR\^",
  617. .IR "\fI_Exit\fR\^(\|)",
  618. .IR "\fIkill\fR\^(\|)",
  619. .IR "\fI_longjmp\fR\^(\|)",
  620. .IR "\fIlongjmp\fR\^(\|)",
  621. .IR "\fIpthread_sigmask\fR\^(\|)",
  622. .IR "\fIraise\fR\^(\|)",
  623. .IR "\fIsemget\fR\^(\|)",
  624. .IR "\fIsem_init\fR\^(\|)",
  625. .IR "\fIsem_open\fR\^(\|)",
  626. .IR "\fIsigaddset\fR\^(\|)",
  627. .IR "\fIsigaltstack\fR\^(\|)",
  628. .IR "\fIsigdelset\fR\^(\|)",
  629. .IR "\fIsigemptyset\fR\^(\|)",
  630. .IR "\fIsigfillset\fR\^(\|)",
  631. .IR "\fIsigismember\fR\^(\|)",
  632. .IR "\fIsignal\fR\^(\|)",
  633. .IR "\fIsigsuspend\fR\^(\|)",
  634. .IR "\fIwait\fR\^(\|)",
  635. .IR "\fIwaitid\fR\^(\|)"
  636. .P
  637. The Base Definitions volume of POSIX.1\(hy2017,
  638. .IR "\fB<signal.h>\fP"
  639. .\"
  640. .SH COPYRIGHT
  641. Portions of this text are reprinted and reproduced in electronic form
  642. from IEEE Std 1003.1-2017, Standard for Information Technology
  643. -- Portable Operating System Interface (POSIX), The Open Group Base
  644. Specifications Issue 7, 2018 Edition,
  645. Copyright (C) 2018 by the Institute of
  646. Electrical and Electronics Engineers, Inc and The Open Group.
  647. In the event of any discrepancy between this version and the original IEEE and
  648. The Open Group Standard, the original IEEE and The Open Group Standard
  649. is the referee document. The original Standard can be obtained online at
  650. http://www.opengroup.org/unix/online.html .
  651. .PP
  652. Any typographical or formatting errors that appear
  653. in this page are most likely
  654. to have been introduced during the conversion of the source files to
  655. man page format. To report such errors, see
  656. https://www.kernel.org/doc/man-pages/reporting_bugs.html .