SIGNAL(7) Linux Programmer's Manual SIGNAL(7) NNAAMMEE signal - list of available signals DDEESSCCRRIIPPTTIIOONN Linux supports both POSIX reliable signals (hereinafter "standard sig- nals") and POSIX real-time signals. SSttaannddaarrdd SSiiggnnaallss Linux supports the standard signals listed below. Several signal num- bers are architecture dependent, as indicated in the "Value" column. (Where three values are given, the first one is usually valid for alpha and sparc, the middle one for i386, ppc and sh, and the last one for mips. A - denotes that a signal is absent on the corresponding archi- tecture.) The entries in the "Action" column of the table specify the default action for the signal, as follows: Term Default action is to terminate the process. Ign Default action is to ignore the signal. Core Default action is to terminate the process and dump core. Stop Default action is to stop the process. First the signals described in the original POSIX.1 standard. Signal Value Action Comment ------------------------------------------------------------------------- SSIIGGHHUUPP 1 Term Hangup detected on controlling terminal or death of controlling process SSIIGGIINNTT 2 Term Interrupt from keyboard SSIIGGQQUUIITT 3 Core Quit from keyboard SSIIGGIILLLL 4 Core Illegal Instruction SSIIGGAABBRRTT 6 Core Abort signal from _a_b_o_r_t(3) SSIIGGFFPPEE 8 Core Floating point exception SSIIGGKKIILLLL 9 Term Kill signal SSIIGGSSEEGGVV 11 Core Invalid memory reference SSIIGGPPIIPPEE 13 Term Broken pipe: write to pipe with no readers SSIIGGAALLRRMM 14 Term Timer signal from _a_l_a_r_m(2) SSIIGGTTEERRMM 15 Term Termination signal SSIIGGUUSSRR11 30,10,16 Term User-defined signal 1 SSIIGGUUSSRR22 31,12,17 Term User-defined signal 2 SSIIGGCCHHLLDD 20,17,18 Ign Child stopped or terminated SSIIGGCCOONNTT 19,18,25 Continue if stopped SSIIGGSSTTOOPP 17,19,23 Stop Stop process SSIIGGTTSSTTPP 18,20,24 Stop Stop typed at tty SSIIGGTTTTIINN 21,21,26 Stop tty input for background process SSIIGGTTTTOOUU 22,22,27 Stop tty output for background process The signals SSIIGGKKIILLLL and SSIIGGSSTTOOPP cannot be caught, blocked, or ignored. Next the signals not in the POSIX.1 standard but described in SUSv2 and SUSv3 / POSIX 1003.1-2001. Signal Value Action Comment ------------------------------------------------------------------------- SSIIGGBBUUSS 10,7,10 Core Bus error (bad memory access) SSIIGGPPOOLLLL Term Pollable event (Sys V). Synonym of SIGIO SSIIGGPPRROOFF 27,27,29 Term Profiling timer expired SSIIGGSSYYSS 12,-,12 Core Bad argument to routine (SVID) SSIIGGTTRRAAPP 5 Core Trace/breakpoint trap SSIIGGUURRGG 16,23,21 Ign Urgent condition on socket (4.2 BSD) SSIIGGVVTTAALLRRMM 26,26,28 Term Virtual alarm clock (4.2 BSD) SSIIGGXXCCPPUU 24,24,30 Core CPU time limit exceeded (4.2 BSD) SSIIGGXXFFSSZZ 25,25,31 Core File size limit exceeded (4.2 BSD) Up to and including Linux 2.2, the default behaviour for SSIIGGSSYYSS, SSIIGGXX-- CCPPUU, SSIIGGXXFFSSZZ, and (on architectures other than SPARC and MIPS) SSIIGGBBUUSS was to terminate the process (without a core dump). (On some other Unices the default action for SSIIGGXXCCPPUU and SSIIGGXXFFSSZZ is to terminate the process without a core dump.) Linux 2.4 conforms to the POSIX 1003.1-2001 requirements for these signals, terminating the process with a core dump. Next various other signals. Signal Value Action Comment -------------------------------------------------------------------- SSIIGGIIOOTT 6 Core IOT trap. A synonym for SIGABRT SSIIGGEEMMTT 7,-,7 Term SSIIGGSSTTKKFFLLTT -,16,- Term Stack fault on coprocessor (unused) SSIIGGIIOO 23,29,22 Term I/O now possible (4.2 BSD) SSIIGGCCLLDD -,-,18 Ign A synonym for SIGCHLD SSIIGGPPWWRR 29,30,19 Term Power failure (System V) SSIIGGIINNFFOO 29,-,- A synonym for SIGPWR SSIIGGLLOOSSTT -,-,- Term File lock lost SSIIGGWWIINNCCHH 28,28,20 Ign Window resize signal (4.3 BSD, Sun) SSIIGGUUNNUUSSEEDD -,31,- Term Unused signal (will be SIGSYS) (Signal 29 is SSIIGGIINNFFOO / SSIIGGPPWWRR on an alpha but SSIIGGLLOOSSTT on a sparc.) SSIIGGEEMMTT is not specified in POSIX 1003.1-2001, but neverthless appears on most other Unices, where its default action is typically to termi- nate the process with a core dump. SSIIGGPPWWRR (which is not specified in POSIX 1003.1-2001) is typically ignored by default on those other Unices where it appears. SSIIGGIIOO (which is not specified in POSIX 1003.1-2001) is ignored by default on several other Unices. RReeaall--ttiimmee SSiiggnnaallss Linux supports real-time signals as originally defined in the POSIX.4 real-time extensions (and now included in POSIX 1003.1-2001). Linux supports 32 real-time signals, numbered from 32 (SSIIGGRRTTMMIINN) to 63 (SSIIGGRRTTMMAAXX). (Programs should always refer to real-time signals using notation SSIIGGRRTTMMIINN+n, since the range of real-time signal numbers varies across Unices.) Unlike standard signals, real-time signals have no predefined meanings: the entire set of real-time signals can be used for application-defined purposes. (Note, however, that the LinuxThreads implementation uses the first three real-time signals.) The default action for an unhandled real-time signal is to terminate the receiving process. Real-time signals are distinguished by the following: 1. Multiple instances of real-time signals can be queued. By con- trast, if multiple instances of a standard signal are delivered while that signal is currently blocked, then only one instance is queued. 2. If the signal is sent using ssiiggqquueeuuee(2), an accompanying value (either an integer or a pointer) can be sent with the signal. If the receiving process establishes a handler for this signal using the SSAA__SSIIGGAACCTTIIOONN flag to ssiiggaaccttiioonn(2) then it can obtain this data via the _s_i___v_a_l_u_e field of the _s_i_g_i_n_f_o___t structure passed as the second argument to the handler. Furthermore, the _s_i___p_i_d and _s_i___u_i_d fields of this structure can be used to obtain the PID and real user ID of the process sending the signal. 3. Real-time signals are delivered in a guaranteed order. Multiple real-time signals of the same type are delivered in the order they were sent. If different real-time signals are sent to a process, they are delivered starting with the lowest-numbered signal. (I.e., low-numbered signals have highest priority.) If both standard and real-time signals are pending for a process, POSIX leaves it unspecified which is delivered first. Linux, like many other implementations, gives priority to standard signals in this case. According to POSIX, an implementation should permit at least _POSIX_SIGQUEUE_MAX (32) real-time signals to be queued to a process. However, rather than placing a per-process limit, Linux imposes a sys- tem-wide limit on the number of queued real-time signals for all pro- cesses. This limit can be viewed and (with privilege) changed via the _/_p_r_o_c_/_s_y_s_/_k_e_r_n_e_l_/_r_t_s_i_g_-_m_a_x file. A related file, _/_p_r_o_c_/_s_y_s_/_k_e_r_- _n_e_l_/_r_t_s_i_g_-_n_r, can be used to find out how many real-time signals are currently queued. CCOONNFFOORRMMIINNGG TTOO POSIX.1 BBUUGGSS SSIIGGIIOO and SSIIGGLLOOSSTT have the same value. The latter is commented out in the kernel source, but the build process of some software still thinks that signal 29 is SSIIGGLLOOSSTT. SSEEEE AALLSSOO kkiillll(1), kkiillll(2), sseettiittiimmeerr(2), ssiiggaaccttiioonn(2), ssiiggnnaall(2), ssiiggpprroocc-- mmaasskk(2), ssiiggqquueeuuee(2) Linux 2.4.18 2002-06-13 SIGNAL(7)