original/man7/signal.7

   1 '\" t
   2 .\" Copyright (c) 1993 by Thomas Koenig (ig25@rz.uni-karlsruhe.de)
   3 .\" and Copyright (c) 2002, 2006 by Michael Kerrisk <mtk.manpages@gmail.com>
   4 .\" and Copyright (c) 2008 Linux Foundation, written by Michael Kerrisk
   5 .\"     <mtk.manpages@gmail.com>
   6 .\"
   7 .\" %%%LICENSE_START(VERBATIM)
   8 .\" Permission is granted to make and distribute verbatim copies of this
   9 .\" manual provided the copyright notice and this permission notice are
  10 .\" preserved on all copies.
  11 .\"
  12 .\" Permission is granted to copy and distribute modified versions of this
  13 .\" manual under the conditions for verbatim copying, provided that the
  14 .\" entire resulting derived work is distributed under the terms of a
  15 .\" permission notice identical to this one.
  16 .\"
  17 .\" Since the Linux kernel and libraries are constantly changing, this
  18 .\" manual page may be incorrect or out-of-date.  The author(s) assume no
  19 .\" responsibility for errors or omissions, or for damages resulting from
  20 .\" the use of the information contained herein.  The author(s) may not
  21 .\" have taken the same level of care in the production of this manual,
  22 .\" which is licensed free of charge, as they might when working
  23 .\" professionally.
  24 .\"
  25 .\" Formatted or processed versions of this manual, if unaccompanied by
  26 .\" the source, must acknowledge the copyright and authors of this work.
  27 .\" %%%LICENSE_END
  28 .\"
  29 .\" Modified Sat Jul 24 17:34:08 1993 by Rik Faith (faith@cs.unc.edu)
  30 .\" Modified Sun Jan  7 01:41:27 1996 by Andries Brouwer (aeb@cwi.nl)
  31 .\" Modified Sun Apr 14 12:02:29 1996 by Andries Brouwer (aeb@cwi.nl)
  32 .\" Modified Sat Nov 13 16:28:23 1999 by Andries Brouwer (aeb@cwi.nl)
  33 .\" Modified 10 Apr 2002, by Michael Kerrisk <mtk.manpages@gmail.com>
  34 .\" Modified  7 Jun 2002, by Michael Kerrisk <mtk.manpages@gmail.com>
  35 .\"     Added information on real-time signals
  36 .\" Modified 13 Jun 2002, by Michael Kerrisk <mtk.manpages@gmail.com>
  37 .\"     Noted that SIGSTKFLT is in fact unused
  38 .\" 2004-12-03, Modified mtk, added notes on RLIMIT_SIGPENDING
  39 .\" 2006-04-24, mtk, Added text on changing signal dispositions,
  40 .\"             signal mask, and pending signals.
  41 .\" 2008-07-04, mtk:
  42 .\"     Added section on system call restarting (SA_RESTART)
  43 .\"     Added section on stop/cont signals interrupting syscalls.
  44 .\" 2008-10-05, mtk: various additions
  45 .\"
  46 .TH SIGNAL 7  2013-07-30 "Linux" "Linux Programmer's Manual"
  47 .SH NAME
  48 signal \- overview of signals
  49 .SH DESCRIPTION
  50 Linux supports both POSIX reliable signals (hereinafter
  51 "standard signals") and POSIX real-time signals.
  52 .SS Signal dispositions
  53 Each signal has a current
  54 .IR disposition ,
  55 which determines how the process behaves when it is delivered
  56 the signal.
  57
  58 The entries in the "Action" column of the tables below specify
  59 the default disposition for each signal, as follows:
  60 .IP Term
  61 Default action is to terminate the process.
  62 .IP Ign
  63 Default action is to ignore the signal.
  64 .IP Core
  65 Default action is to terminate the process and dump core (see
  66 .BR core (5)).
  67 .IP Stop
  68 Default action is to stop the process.
  69 .IP Cont
  70 Default action is to continue the process if it is currently stopped.
  71 .PP
  72 A process can change the disposition of a signal using
  73 .BR sigaction (2)
  74 or
  75 .BR signal (2).
  76 (The latter is less portable when establishing a signal handler;
  77 see
  78 .BR signal (2)
  79 for details.)
  80 Using these system calls, a process can elect one of the
  81 following behaviors to occur on delivery of the signal:
  82 perform the default action; ignore the signal;
  83 or catch the signal with a
  84 .IR "signal handler" ,
  85 a programmer-defined function that is automatically invoked
  86 when the signal is delivered.
  87 (By default, the signal handler is invoked on the
  88 normal process stack.
  89 It is possible to arrange that the signal handler
  90 uses an alternate stack; see
  91 .BR sigaltstack (2)
  92 for a discussion of how to do this and when it might be useful.)
  93
  94 The signal disposition is a per-process attribute:
  95 in a multithreaded application, the disposition of a
  96 particular signal is the same for all threads.
  97
  98 A child created via
  99 .BR fork (2)
 100 inherits a copy of its parent's signal dispositions.
 101 During an
 102 .BR execve (2),
 103 the dispositions of handled signals are reset to the default;
 104 the dispositions of ignored signals are left unchanged.
 105 .SS Sending a signal
 106 The following system calls and library functions allow
 107 the caller to send a signal:
 108 .TP 16
 109 .BR raise (3)
 110 Sends a signal to the calling thread.
 111 .TP
 112 .BR kill (2)
 113 Sends a signal to a specified process,
 114 to all members of a specified process group,
 115 or to all processes on the system.
 116 .TP
 117 .BR killpg (2)
 118 Sends a signal to all of the members of a specified process group.
 119 .TP
 120 .BR pthread_kill (3)
 121 Sends a signal to a specified POSIX thread in the same process as
 122 the caller.
 123 .TP
 124 .BR tgkill (2)
 125 Sends a signal to a specified thread within a specific process.
 126 (This is the system call used to implement
 127 .BR pthread_kill (3).)
 128 .TP
 129 .BR sigqueue (3)
 130 Sends a real-time signal with accompanying data to a specified process.
 131 .SS Waiting for a signal to be caught
 132 The following system calls suspend execution of the calling process
 133 or thread until a signal is caught
 134 (or an unhandled signal terminates the process):
 135 .TP 16
 136 .BR pause (2)
 137 Suspends execution until any signal is caught.
 138 .TP
 139 .BR sigsuspend (2)
 140 Temporarily changes the signal mask (see below) and suspends
 141 execution until one of the unmasked signals is caught.
 142 .SS Synchronously accepting a signal
 143 Rather than asynchronously catching a signal via a signal handler,
 144 it is possible to synchronously accept the signal, that is,
 145 to block execution until the signal is delivered,
 146 at which point the kernel returns information about the
 147 signal to the caller.
 148 There are two general ways to do this:
 149 .IP * 2
 150 .BR sigwaitinfo (2),
 151 .BR sigtimedwait (2),
 152 and
 153 .BR sigwait (3)
 154 suspend execution until one of the signals in a specified
 155 set is delivered.
 156 Each of these calls returns information about the delivered signal.
 157 .IP *
 158 .BR signalfd (2)
 159 returns a file descriptor that can be used to read information
 160 about signals that are delivered to the caller.
 161 Each
 162 .BR read (2)
 163 from this file descriptor blocks until one of the signals
 164 in the set specified in the
 165 .BR signalfd (2)
 166 call is delivered to the caller.
 167 The buffer returned by
 168 .BR read (2)
 169 contains a structure describing the signal.
 170 .SS Signal mask and pending signals
 171 A signal may be
 172 .IR blocked ,
 173 which means that it will not be delivered until it is later unblocked.
 174 Between the time when it is generated and when it is delivered
 175 a signal is said to be
 176 .IR pending .
 177
 178 Each thread in a process has an independent
 179 .IR "signal mask" ,
 180 which indicates the set of signals that the thread is currently blocking.
 181 A thread can manipulate its signal mask using
 182 .BR pthread_sigmask (3).
 183 In a traditional single-threaded application,
 184 .BR sigprocmask (2)
 185 can be used to manipulate the signal mask.
 186
 187 A child created via
 188 .BR fork (2)
 189 inherits a copy of its parent's signal mask;
 190 the signal mask is preserved across
 191 .BR execve (2).
 192
 193 A signal may be generated (and thus pending)
 194 for a process as a whole (e.g., when sent using
 195 .BR kill (2))
 196 or for a specific thread (e.g., certain signals,
 197 such as
 198 .B SIGSEGV
 199 and
 200 .BR SIGFPE ,
 201 generated as a
 202 consequence of executing a specific machine-language instruction
 203 are thread directed, as are signals targeted at a specific thread using
 204 .BR pthread_kill (3)).
 205 A process-directed signal may be delivered to any one of the
 206 threads that does not currently have the signal blocked.
 207 If more than one of the threads has the signal unblocked, then the
 208 kernel chooses an arbitrary thread to which to deliver the signal.
 209
 210 A thread can obtain the set of signals that it currently has pending
 211 using
 212 .BR sigpending (2).
 213 This set will consist of the union of the set of pending
 214 process-directed signals and the set of signals pending for
 215 the calling thread.
 216
 217 A child created via
 218 .BR fork (2)
 219 initially has an empty pending signal set;
 220 the pending signal set is preserved across an
 221 .BR execve (2).
 222 .SS Standard signals
 223 Linux supports the standard signals listed below.
 224 Several signal numbers
 225 are architecture-dependent, as indicated in the "Value" column.
 226 (Where three values are given, the first one is usually valid for
 227 alpha and sparc,
 228 the middle one for x86, arm, and most other architectures,
 229 and the last one for mips.
 230 (Values for parisc are
 231 .I not
 232 shown; see the Linux kernel source for signal numbering on that architecture.)
 233 A \- denotes that a signal is absent on the corresponding architecture.)
 234
 235 First the signals described in the original POSIX.1-1990 standard.
 236 .TS
 237 l c c l
 238 ____
 239 lB c c l.
 240 Signal  Value   Action  Comment
 241 SIGHUP  \01     Term    Hangup detected on controlling terminal
 242                         or death of controlling process
 243 SIGINT  \02     Term    Interrupt from keyboard
 244 SIGQUIT \03     Core    Quit from keyboard
 245 SIGILL  \04     Core    Illegal Instruction
 246 SIGABRT \06     Core    Abort signal from \fBabort\fP(3)
 247 SIGFPE  \08     Core    Floating point exception
 248 SIGKILL \09     Term    Kill signal
 249 SIGSEGV 11      Core    Invalid memory reference
 250 SIGPIPE 13      Term    Broken pipe: write to pipe with no
 251                         readers
 252 SIGALRM 14      Term    Timer signal from \fBalarm\fP(2)
 253 SIGTERM 15      Term    Termination signal
 254 SIGUSR1 30,10,16        Term    User-defined signal 1
 255 SIGUSR2 31,12,17        Term    User-defined signal 2
 256 SIGCHLD 20,17,18        Ign     Child stopped or terminated
 257 SIGCONT 19,18,25        Cont    Continue if stopped
 258 SIGSTOP 17,19,23        Stop    Stop process
 259 SIGTSTP 18,20,24        Stop    Stop typed at terminal
 260 SIGTTIN 21,21,26        Stop    Terminal input for background process
 261 SIGTTOU 22,22,27        Stop    Terminal output for background process
 262 .TE
 263
 264 The signals
 265 .B SIGKILL
 266 and
 267 .B SIGSTOP
 268 cannot be caught, blocked, or ignored.
 269
 270 Next the signals not in the POSIX.1-1990 standard but described in
 271 SUSv2 and POSIX.1-2001.
 272 .TS
 273 l c c l
 274 ____
 275 lB c c l.
 276 Signal  Value   Action  Comment
 277 SIGBUS  10,7,10 Core    Bus error (bad memory access)
 278 SIGPOLL         Term    Pollable event (Sys V).
 279                         Synonym for \fBSIGIO\fP
 280 SIGPROF 27,27,29        Term    Profiling timer expired
 281 SIGSYS  12,31,12        Core    Bad argument to routine (SVr4)
 282 SIGTRAP 5       Core    Trace/breakpoint trap
 283 SIGURG  16,23,21        Ign     Urgent condition on socket (4.2BSD)
 284 SIGVTALRM       26,26,28        Term    Virtual alarm clock (4.2BSD)
 285 SIGXCPU 24,24,30        Core    CPU time limit exceeded (4.2BSD)
 286 SIGXFSZ 25,25,31        Core    File size limit exceeded (4.2BSD)
 287 .TE
 288
 289 Up to and including Linux 2.2, the default behavior for
 290 .BR SIGSYS ", " SIGXCPU ", " SIGXFSZ ", "
 291 and (on architectures other than SPARC and MIPS)
 292 .B SIGBUS
 293 was to terminate the process (without a core dump).
 294 (On some other UNIX systems the default action for
 295 .BR SIGXCPU " and " SIGXFSZ
 296 is to terminate the process without a core dump.)
 297 Linux 2.4 conforms to the POSIX.1-2001 requirements for these signals,
 298 terminating the process with a core dump.
 299
 300 Next various other signals.
 301 .TS
 302 l c c l
 303 ____
 304 lB c c l.
 305 Signal  Value   Action  Comment
 306 SIGIOT  6       Core    IOT trap. A synonym for \fBSIGABRT\fP
 307 SIGEMT  7,\-,7  Term
 308 SIGSTKFLT       \-,16,\-        Term    Stack fault on coprocessor (unused)
 309 SIGIO   23,29,22        Term    I/O now possible (4.2BSD)
 310 SIGCLD  \-,\-,18        Ign     A synonym for \fBSIGCHLD\fP
 311 SIGPWR  29,30,19        Term    Power failure (System V)
 312 SIGINFO 29,\-,\-                A synonym for \fBSIGPWR\fP
 313 SIGLOST \-,\-,\-        Term    File lock lost (unused)
 314 SIGWINCH        28,28,20        Ign     Window resize signal (4.3BSD, Sun)
 315 SIGUNUSED       \-,31,\-        Core    Synonymous with \fBSIGSYS\fP
 316 .TE
 317
 318 (Signal 29 is
 319 .B SIGINFO
 320 /
 321 .B SIGPWR
 322 on an alpha but
 323 .B SIGLOST
 324 on a sparc.)
 325
 326 .B SIGEMT
 327 is not specified in POSIX.1-2001, but nevertheless appears
 328 on most other UNIX systems,
 329 where its default action is typically to terminate
 330 the process with a core dump.
 331
 332 .B SIGPWR
 333 (which is not specified in POSIX.1-2001) is typically ignored
 334 by default on those other UNIX systems where it appears.
 335
 336 .B SIGIO
 337 (which is not specified in POSIX.1-2001) is ignored by default
 338 on several other UNIX systems.
 339
 340 Where defined,
 341 .B SIGUNUSED
 342 is synonymous with
 343 .\" parisc is the only exception: SIGSYS is 12, SIGUNUSED is 31
 344 .B SIGSYS
 345 on most architectures.
 346 .SS Real-time signals
 347 Linux supports real-time signals as originally defined in the POSIX.1b
 348 real-time extensions (and now included in POSIX.1-2001).
 349 The range of supported real-time signals is defined by the macros
 350 .B SIGRTMIN
 351 and
 352 .BR SIGRTMAX .
 353 POSIX.1-2001 requires that an implementation support at least
 354 .B _POSIX_RTSIG_MAX
 355 (8) real-time signals.
 356 .PP
 357 The Linux kernel supports a range of 32 different real-time
 358 signals, numbered 33 to 64.
 359 However, the glibc POSIX threads implementation internally uses
 360 two (for NPTL) or three (for LinuxThreads) real-time signals
 361 (see
 362 .BR pthreads (7)),
 363 and adjusts the value of
 364 .B SIGRTMIN
 365 suitably (to 34 or 35).
 366 Because the range of available real-time signals varies according
 367 to the glibc threading implementation (and this variation can occur
 368 at run time according to the available kernel and glibc),
 369 and indeed the range of real-time signals varies across UNIX systems,
 370 programs should
 371 .IR "never refer to real-time signals using hard-coded numbers" ,
 372 but instead should always refer to real-time signals using the notation
 373 .BR SIGRTMIN +n,
 374 and include suitable (run-time) checks that
 375 .BR SIGRTMIN +n
 376 does not exceed
 377 .BR SIGRTMAX .
 378 .PP
 379 Unlike standard signals, real-time signals have no predefined meanings:
 380 the entire set of real-time signals can be used for application-defined
 381 purposes.
 382 .PP
 383 The default action for an unhandled real-time signal is to terminate the
 384 receiving process.
 385 .PP
 386 Real-time signals are distinguished by the following:
 387 .IP 1. 4
 388 Multiple instances of real-time signals can be queued.
 389 By contrast, if multiple instances of a standard signal are delivered
 390 while that signal is currently blocked, then only one instance is queued.
 391 .IP 2. 4
 392 If the signal is sent using
 393 .BR sigqueue (3),
 394 an accompanying value (either an integer or a pointer) can be sent
 395 with the signal.
 396 If the receiving process establishes a handler for this signal using the
 397 .B SA_SIGINFO
 398 flag to
 399 .BR sigaction (2),
 400 then it can obtain this data via the
 401 .I si_value
 402 field of the
 403 .I siginfo_t
 404 structure passed as the second argument to the handler.
 405 Furthermore, the
 406 .I si_pid
 407 and
 408 .I si_uid
 409 fields of this structure can be used to obtain the PID
 410 and real user ID of the process sending the signal.
 411 .IP 3. 4
 412 Real-time signals are delivered in a guaranteed order.
 413 Multiple real-time signals of the same type are delivered in the order
 414 they were sent.
 415 If different real-time signals are sent to a process, they are delivered
 416 starting with the lowest-numbered signal.
 417 (I.e., low-numbered signals have highest priority.)
 418 By contrast, if multiple standard signals are pending for a process,
 419 the order in which they are delivered is unspecified.
 420 .PP
 421 If both standard and real-time signals are pending for a process,
 422 POSIX leaves it unspecified which is delivered first.
 423 Linux, like many other implementations, gives priority
 424 to standard signals in this case.
 425 .PP
 426 According to POSIX, an implementation should permit at least
 427 .B _POSIX_SIGQUEUE_MAX
 428 (32) real-time signals to be queued to
 429 a process.
 430 However, Linux does things differently.
 431 In kernels up to and including 2.6.7, Linux imposes
 432 a system-wide limit on the number of queued real-time signals
 433 for all processes.
 434 This limit can be viewed and (with privilege) changed via the
 435 .I /proc/sys/kernel/rtsig-max
 436 file.
 437 A related file,
 438 .IR /proc/sys/kernel/rtsig-nr ,
 439 can be used to find out how many real-time signals are currently queued.
 440 In Linux 2.6.8, these
 441 .I /proc
 442 interfaces were replaced by the
 443 .B RLIMIT_SIGPENDING
 444 resource limit, which specifies a per-user limit for queued
 445 signals; see
 446 .BR setrlimit (2)
 447 for further details.
 448 .SS Async-signal-safe functions
 449 .PP
 450 A signal handler function must be very careful,
 451 since processing elsewhere may be interrupted
 452 at some arbitrary point in the execution of the program.
 453 POSIX has the concept of "safe function".
 454 If a signal interrupts the execution of an unsafe function, and
 455 .I handler
 456 calls an unsafe function, then the behavior of the program is undefined.
 457
 458 POSIX.1-2004 (also known as POSIX.1-2001 Technical Corrigendum 2)
 459 requires an implementation to guarantee that the following
 460 functions can be safely called inside a signal handler:
 461
 462 .in +4
 463 .nf
 464 _Exit()
 465 _exit()
 466 abort()
 467 accept()
 468 access()
 469 aio_error()
 470 aio_return()
 471 aio_suspend()
 472 alarm()
 473 bind()
 474 cfgetispeed()
 475 cfgetospeed()
 476 cfsetispeed()
 477 cfsetospeed()
 478 chdir()
 479 chmod()
 480 chown()
 481 clock_gettime()
 482 close()
 483 connect()
 484 creat()
 485 dup()
 486 dup2()
 487 execle()
 488 execve()
 489 fchmod()
 490 fchown()
 491 fcntl()
 492 fdatasync()
 493 fork()
 494 fpathconf()
 495 fstat()
 496 fsync()
 497 ftruncate()
 498 getegid()
 499 geteuid()
 500 getgid()
 501 getgroups()
 502 getpeername()
 503 getpgrp()
 504 getpid()
 505 getppid()
 506 getsockname()
 507 getsockopt()
 508 getuid()
 509 kill()
 510 link()
 511 listen()
 512 lseek()
 513 lstat()
 514 mkdir()
 515 mkfifo()
 516 open()
 517 pathconf()
 518 pause()
 519 pipe()
 520 poll()
 521 posix_trace_event()
 522 pselect()
 523 raise()
 524 read()
 525 readlink()
 526 recv()
 527 recvfrom()
 528 recvmsg()
 529 rename()
 530 rmdir()
 531 select()
 532 sem_post()
 533 send()
 534 sendmsg()
 535 sendto()
 536 setgid()
 537 setpgid()
 538 setsid()
 539 setsockopt()
 540 setuid()
 541 shutdown()
 542 sigaction()
 543 sigaddset()
 544 sigdelset()
 545 sigemptyset()
 546 sigfillset()
 547 sigismember()
 548 signal()
 549 sigpause()
 550 sigpending()
 551 sigprocmask()
 552 sigqueue()
 553 sigset()
 554 sigsuspend()
 555 sleep()
 556 sockatmark()
 557 socket()
 558 socketpair()
 559 stat()
 560 symlink()
 561 sysconf()
 562 tcdrain()
 563 tcflow()
 564 tcflush()
 565 tcgetattr()
 566 tcgetpgrp()
 567 tcsendbreak()
 568 tcsetattr()
 569 tcsetpgrp()
 570 time()
 571 timer_getoverrun()
 572 timer_gettime()
 573 timer_settime()
 574 times()
 575 umask()
 576 uname()
 577 unlink()
 578 utime()
 579 wait()
 580 waitpid()
 581 write()
 582 .fi
 583 .in
 584 .PP
 585 POSIX.1-2008 removes fpathconf(), pathconf(), and sysconf()
 586 from the above list, and adds the following functions:
 587 .PP
 588 .in +4n
 589 .nf
 590 execl()
 591 execv()
 592 faccessat()
 593 fchmodat()
 594 fchownat()
 595 fexecve()
 596 fstatat()
 597 futimens()
 598 linkat()
 599 mkdirat()
 600 mkfifoat()
 601 mknod()
 602 mknodat()
 603 openat()
 604 readlinkat()
 605 renameat()
 606 symlinkat()
 607 unlinkat()
 608 utimensat()
 609 utimes()
 610 .fi
 611 .in
 612 .SS Interruption of system calls and library functions by signal handlers
 613 If a signal handler is invoked while a system call or library
 614 function call is blocked, then either:
 615 .IP * 2
 616 the call is automatically restarted after the signal handler returns; or
 617 .IP *
 618 the call fails with the error
 619 .BR EINTR .
 620 .PP
 621 Which of these two behaviors occurs depends on the interface and
 622 whether or not the signal handler was established using the
 623 .BR SA_RESTART
 624 flag (see
 625 .BR sigaction (2)).
 626 The details vary across UNIX systems;
 627 below, the details for Linux.
 628
 629 If a blocked call to one of the following interfaces is interrupted
 630 by a signal handler, then the call will be automatically restarted
 631 after the signal handler returns if the
 632 .BR SA_RESTART
 633 flag was used; otherwise the call will fail with the error
 634 .BR EINTR :
 635 .\" The following system calls use ERESTARTSYS,
 636 .\" so that they are restartable
 637 .RS 4
 638 .IP * 2
 639 .BR read (2),
 640 .BR readv (2),
 641 .BR write (2),
 642 .BR writev (2),
 643 and
 644 .BR ioctl (2)
 645 calls on "slow" devices.
 646 A "slow" device is one where the I/O call may block for an
 647 indefinite time, for example, a terminal, pipe, or socket.
 648 (A disk is not a slow device according to this definition.)
 649 If an I/O call on a slow device has already transferred some
 650 data by the time it is interrupted by a signal handler,
 651 then the call will return a success status
 652 (normally, the number of bytes transferred).
 653 .IP *
 654 .BR open (2),
 655 if it can block (e.g., when opening a FIFO; see
 656 .BR fifo (7)).
 657 .IP *
 658 .BR wait (2),
 659 .BR wait3 (2),
 660 .BR wait4 (2),
 661 .BR waitid (2),
 662 and
 663 .BR waitpid (2).
 664 .IP *
 665 Socket interfaces:
 666 .\" If a timeout (setsockopt()) is in effect on the socket, then these
 667 .\" system calls switch to using EINTR.  Consequently, they and are not
 668 .\" automatically restarted, and they show the stop/cont behavior
 669 .\" described below.  (Verified from 2.6.26 source, and by experiment; mtk)
 670 .BR accept (2),
 671 .BR connect (2),
 672 .BR recv (2),
 673 .BR recvfrom (2),
 674 .BR recvmsg (2),
 675 .BR send (2),
 676 .BR sendto (2),
 677 and
 678 .BR sendmsg (2),
 679 unless a timeout has been set on the socket (see below).
 680 .IP *
 681 File locking interfaces:
 682 .BR flock (2)
 683 and
 684 .BR fcntl (2)
 685 .BR F_SETLKW .
 686 .IP *
 687 POSIX message queue interfaces:
 688 .BR mq_receive (3),
 689 .BR mq_timedreceive (3),
 690 .BR mq_send (3),
 691 and
 692 .BR mq_timedsend (3).
 693 .IP *
 694 .BR futex (2)
 695 .B FUTEX_WAIT
 696 (since Linux 2.6.22; beforehand, always failed with
 697 .BR EINTR ).
 698 .IP *
 699 POSIX semaphore interfaces:
 700 .BR sem_wait (3)
 701 and
 702 .BR sem_timedwait (3)
 703 (since Linux 2.6.22; beforehand, always failed with
 704 .BR EINTR ).
 705 .RE
 706 .PP
 707 The following interfaces are never restarted after
 708 being interrupted by a signal handler,
 709 regardless of the use of
 710 .BR SA_RESTART ;
 711 they always fail with the error
 712 .B EINTR
 713 when interrupted by a signal handler:
 714 .\" These are the system calls that give EINTR or ERESTARTNOHAND
 715 .\" on interruption by a signal handler.
 716 .RS 4
 717 .IP * 2
 718 Socket interfaces, when a timeout has been set on the socket using
 719 .BR setsockopt (2):
 720 .BR accept (2),
 721 .BR recv (2),
 722 .BR recvfrom (2),
 723 and
 724 .BR recvmsg (2),
 725 if a receive timeout
 726 .RB ( SO_RCVTIMEO )
 727 has been set;
 728 .BR connect (2),
 729 .BR send (2),
 730 .BR sendto (2),
 731 and
 732 .BR sendmsg (2),
 733 if a send timeout
 734 .RB ( SO_SNDTIMEO )
 735 has been set.
 736 .IP *
 737 Interfaces used to wait for signals:
 738 .BR pause (2),
 739 .BR sigsuspend (2),
 740 .BR sigtimedwait (2),
 741 and
 742 .BR sigwaitinfo (2).
 743 .IP *
 744 File descriptor multiplexing interfaces:
 745 .BR epoll_wait (2),
 746 .BR epoll_pwait (2),
 747 .BR poll (2),
 748 .BR ppoll (2),
 749 .BR select (2),
 750 and
 751 .BR pselect (2).
 752 .IP *
 753 System V IPC interfaces:
 754 .\" On some other systems, SA_RESTART does restart these system calls
 755 .BR msgrcv (2),
 756 .BR msgsnd (2),
 757 .BR semop (2),
 758 and
 759 .BR semtimedop (2).
 760 .IP *
 761 Sleep interfaces:
 762 .BR clock_nanosleep (2),
 763 .BR nanosleep (2),
 764 and
 765 .BR usleep (3).
 766 .IP *
 767 .BR read (2)
 768 from an
 769 .BR inotify (7)
 770 file descriptor.
 771 .IP *
 772 .BR io_getevents (2).
 773 .RE
 774 .PP
 775 The
 776 .BR sleep (3)
 777 function is also never restarted if interrupted by a handler,
 778 but gives a success return: the number of seconds remaining to sleep.
 779 .SS Interruption of system calls and library functions by stop signals
 780 On Linux, even in the absence of signal handlers,
 781 certain blocking interfaces can fail with the error
 782 .BR EINTR
 783 after the process is stopped by one of the stop signals
 784 and then resumed via
 785 .BR SIGCONT .
 786 This behavior is not sanctioned by POSIX.1, and doesn't occur
 787 on other systems.
 788
 789 The Linux interfaces that display this behavior are:
 790 .RS 4
 791 .IP * 2
 792 Socket interfaces, when a timeout has been set on the socket using
 793 .BR setsockopt (2):
 794 .BR accept (2),
 795 .BR recv (2),
 796 .BR recvfrom (2),
 797 and
 798 .BR recvmsg (2),
 799 if a receive timeout
 800 .RB ( SO_RCVTIMEO )
 801 has been set;
 802 .BR connect (2),
 803 .BR send (2),
 804 .BR sendto (2),
 805 and
 806 .BR sendmsg (2),
 807 if a send timeout
 808 .RB ( SO_SNDTIMEO )
 809 has been set.
 810 .IP * 2
 811 .BR epoll_wait (2),
 812 .BR epoll_pwait (2).
 813 .IP *
 814 .BR semop (2),
 815 .BR semtimedop (2).
 816 .IP *
 817 .BR sigtimedwait (2),
 818 .BR sigwaitinfo (2).
 819 .IP *
 820 .BR read (2)
 821 from an
 822 .BR inotify (7)
 823 file descriptor.
 824 .IP *
 825 Linux 2.6.21 and earlier:
 826 .BR futex (2)
 827 .BR FUTEX_WAIT ,
 828 .BR sem_timedwait (3),
 829 .BR sem_wait (3).
 830 .IP *
 831 Linux 2.6.8 and earlier:
 832 .BR msgrcv (2),
 833 .BR msgsnd (2).
 834 .IP *
 835 Linux 2.4 and earlier:
 836 .BR nanosleep (2).
 837 .RE
 838 .SH CONFORMING TO
 839 POSIX.1, except as noted.
 840 .\" It must be a *very* long time since this was true:
 841 .\" .SH BUGS
 842 .\" .B SIGIO
 843 .\" and
 844 .\" .B SIGLOST
 845 .\" have the same value.
 846 .\" The latter is commented out in the kernel source, but
 847 .\" the build process of some software still thinks that
 848 .\" signal 29 is
 849 .\" .BR SIGLOST .
 850 .SH SEE ALSO
 851 .BR kill (1),
 852 .BR getrlimit (2),
 853 .BR kill (2),
 854 .BR killpg (2),
 855 .BR restart_syscall (2),
 856 .BR rt_sigqueueinfo (2),
 857 .BR setitimer (2),
 858 .BR setrlimit (2),
 859 .BR sgetmask (2),
 860 .BR sigaction (2),
 861 .BR sigaltstack (2),
 862 .BR signal (2),
 863 .BR signalfd (2),
 864 .BR sigpending (2),
 865 .BR sigprocmask (2),
 866 .BR sigsuspend (2),
 867 .BR sigwaitinfo (2),
 868 .BR abort (3),
 869 .BR bsd_signal (3),
 870 .BR longjmp (3),
 871 .BR raise (3),
 872 .BR pthread_sigqueue (3),
 873 .BR sigqueue (3),
 874 .BR sigset (3),
 875 .BR sigsetops (3),
 876 .BR sigvec (3),
 877 .BR sigwait (3),
 878 .BR strsignal (3),
 879 .BR sysv_signal (3),
 880 .BR core (5),
 881 .BR proc (5),
 882 .BR pthreads (7),
 883 .BR sigevent (7)
 884 .SH COLOPHON
 885 This page is part of release 3.67 of the Linux
 886 .I man-pages
 887 project.
 888 A description of the project,
 889 information about reporting bugs,
 890 and the latest version of this page,
 891 can be found at
 892 \%http://www.kernel.org/doc/man\-pages/.