.\" -*- coding: UTF-8 -*-
'\" t
.\" Copyright, the authors of the Linux man-pages project
.\"
.\" SPDX-License-Identifier: Linux-man-pages-copyleft
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH signal 7 "17 Mayo 2025" "Páginas de Manual de Linux 6.15" 
.SH NOMBRE
signal \- Breve resumen de la señales
.SH DESCRIPCIÓN
Linux permite tanto las señales POSIX confiables (de aquí en adelante
"señales estándar") como las señales POSIX en tiempo real.
.SS "Disposiciones de señales"
Cada señal tiene una \fIdisposición\fP actual, que determina el comportamiento
del proceso al recibir la señal.
.P
Las entradas de la columna «Acción» de la siguiente tabla definen la
disposición predeterminada para cada señal, como se indica a continuación:
.TP 
Term
La acción por defecto es terminar el proceso.
.TP 
Ign
La acción por defecto es ignorar la señal.
.TP 
Core
La acción por defecto es terminar el proceso y realizar un volcado de
memoria (vea \fBcore\fP(5)).
.TP 
Stop
La acción por defecto es detener el proceso.
.TP 
Cont.
La acción predeterminada es continuar el proceso si está detenido.
.P
Un proceso podrá cambiar la disposición de una señal mediante
\fBsigaction\fP(2) o \fBsignal\fP(2). (Esta última es menos portable al establecer
un gestor de señales; consulte \fBsignal\fP(2) para obtener más
información). Mediante estas llamadas al sistema, un proceso puede elegir
que se produzca uno de los siguientes comportamientos al recibir la señal:
realizar la acción predeterminada, ignorar la señal o capturarla con un
\fIgestor de señal\fP, una función definida por el programador que se invoca
automáticamente al recibir la señal.
.P
Por defecto, un gestor de señales se invoca en la pila de procesos
normal. Es posible configurarlo para que utilice una pila alternativa;
consulte \fBsigaltstack\fP(2) para obtener información sobre cómo hacerlo y
cuándo puede ser útil.
.P
La disposición de la señal es un atributo por proceso: en una aplicación
multihilo, la disposición de una señal específica es la misma para todos los
hilos.
.P
Un subproceso creado mediante \fBfork\fP(2) hereda una copia de la disposición
de las señales de su subproceso principal. Durante una \fBexecve\fP(2), la
disposición de las señales manejadas se restablecerá a la predeterminada. La
disposición de las señales ignoradas se mantiene sin cambios.
.SS "Envío de una señal"
Las siguientes llamadas al sistema y funciones de biblioteca permiten al
llamador enviar una señal:
.TP 
\fBraise\fP(3)
Envía una señal al subproceso que realiza la llamada.
.TP 
\fBkill\fP(2)
Envía una señal a un proceso específico, a todos los miembros de un grupo de
procesos específico o a todos los procesos del sistema.
.TP 
\fBpidfd_send_signal\fP(2)
Envía una señal a un proceso identificado por un descriptor de archivo PID.
.TP 
\fBkillpg\fP(3)
Envía una señal a todos los miembros de un grupo concreto de procesos. Envía
una señal a un hilo POSIX específico en el mismo proceso que el invocador.
.TP 
\fBpthread_kill\fP(3)
Envía una señal a un hilo concreto dentro de un proceso específico. (Esta es
la llamada al sistema utilizada para implementar \fBpthread_kill\fP(3).)
.TP 
\fBtgkill\fP(2)
Envía una señal a un hilo en concreto dentro de un proceso específico. Esta
es la llamada al sistema utilizada para implementar \fBpthread_kill\fP(3).
.TP 
\fBsigqueue\fP(3)
Envía una señal en tiempo real con los datos correspondientes a un proceso
específico.
.SS "Esperando a que se capture una señal"
Las siguientes llamadas al sistema suspenden la ejecución del hilo invocador
hasta que se capture una señal (o una señal no controlada finalice el
proceso):
.TP 
\fBpause\fP(2)
Suspende la ejecución hasta que se capture alguna señal.
.TP 
\fBsigsuspend\fP(2)
.\"
Cambia temporalmente la máscara de la señal (véase más adelante) y suspende
la ejecución hasta que se capture una de las señales no enmascaradas.
.SS "Aceptar una señal sincrónicamente"
En lugar de capturar una señal asincrónicamente mediante un gestor de
señales, es posible aceptar la señal sincrónicamente; es decir, bloquear la
ejecución hasta que se entregue la señal, momento en el que el núcleo
devuelve información sobre la señal al invocador. En general hay dos formas
de hacerlo:
.IP \[bu] 3
\fBsigwaitinfo\fP(2), \fBsigtimedwait\fP(2) y \fBsigwait\fP(3) suspenden la ejecución
hasta que se entrega una de las señales de un conjunto dado. Cada una de
estas llamadas retorna información sobre la señal entregada.
.IP \[bu]
\fBsignalfd\fP(2) devuelve un descriptor de archivo que permite leer
información sobre las señales entregadas al llamante. Cada \fBread\fP(2) de
este descriptor de archivo se bloquea hasta que se entrega al llamante una
de las señales del conjunto especificado en la llamada \fBsignalfd\fP(2). El
búfer devuelto por \fBread\fP(2) contiene una estructura que describe la señal.
.SS "Máscara de señal y señales pendientes"
Una señal puede estar \fIbloqueada\fP, lo que significa que no se entregará
hasta que se desbloquee posteriormente. Entre su generación y su entrega, se
dice que una señal está \fIpendiente\fP.
.P
Cada hilo de un proceso tiene una \fImáscara de señal\fP independiente, que
indica el conjunto de señales que el hilo está bloqueando actualmente. Un
hilo puede manipular su máscara de señal mediante \fBpthread_sigmask\fP(3). En
una aplicación tradicional de un solo hilo, se puede usar \fBsigprocmask\fP(2)
para manipular la máscara de señal.
.P
Un hilo hijo creado mediante \fBfork\fP(2) hereda una copia de la máscara de
señal de su padre; la máscara de señal se conserva en \fBexecve\fP(2).
.P
Una señal puede estar dirigida al proceso o al hilo. Una señal dirigida al
proceso es aquella que está dirigida al proceso en su conjunto (y, por lo
tanto, pendiente de él). Una señal puede estar dirigida al proceso porque
fue generada por el núcleo por razones distintas a una excepción de
hardware, o porque se envió mediante \fBkill\fP(2) o \fBsigqueue\fP(3). Una señal
dirigida al hilo es aquella que está dirigida a un hilo específico. Una
señal puede estar dirigida a un hilo porque se generó como consecuencia de
la ejecución de una instrucción específica en lenguaje de máquina que activó
una excepción de hardware (por ejemplo, \fBSIGSEGV\fP para un acceso a memoria
no válido o \fBSIGFPE\fP para un error matemático) o porque se dirigió a un
hilo específico que utilizaba interfaces como \fBtgkill\fP(2) o
\fBpthread_kill\fP(3).
.P
.\" Joseph C. Sible notes:
.\" On Linux, if the main thread has the signal unblocked, then the kernel
.\" will always deliver the signal there, citing this kernel code
.\"
.\"     Per this comment in kernel/signal.c since time immemorial:
.\"
.\"     /*
.\"     * Now find a thread we can wake up to take the signal off the queue.
.\"     *
.\"     * If the main thread wants the signal, it gets first crack.
.\"     * Probably the least surprising to the average bear.
.\"     */
.\"
.\" But this does not mean the signal will be delivered only in the
.\" main thread, since if a handler is already executing in the main thread
.\" (and thus the signal is blocked in that thread), then a further
.\" might be delivered in a different thread.
.\"
Se puede enviar una señal dirigida por el proceso a cualquiera de los hilos
que no la tengan bloqueada. Si más de un hilo tiene la señal liberada, el
núcleo elige un hilo arbitrario al que enviar la señal.
.P
Un hilo puede obtener el conjunto de señales pendientes mediante
\fBsigping\fP(2). Este conjunto consistirá en la unión del conjunto de señales
pendientes dirigidas por el proceso y el conjunto de señales pendientes para
el hilo que realiza la llamada.
.P
.\"
Un hilo hijo creado mediante \fBfork\fP(2) inicialmente tiene un conjunto de
señales pendientes vacío. Este conjunto se conserva en un \fBexecve\fP(2).
.SS "Ejecución de gestores de señales"
Siempre que se produce una transición del modo núcleo a la ejecución en modo
usuario (por ejemplo, al regresar de una llamada al sistema o al programar
un hilo en la CPU), el núcleo comprueba si hay una señal pendiente
desbloqueada para la cual el proceso haya establecido un gestor de
señales. Si existe dicha señal pendiente, se producen los siguientes pasos:
.IP (1) 5
El núcleo realiza los pasos preparatorios necesarios para la ejecución del
gestor de señales:
.RS
.IP (1.1) 7
La señal se elimina del conjunto de señales pendientes.
.IP (1.2)
Si el gestor de señales se instaló mediante una llamada a \fBsigaction\fP(2)
que definió el indicador \fBSA_ONSTACK\fP y el hilo ha definido una pila de
señales alternativa (mediante \fBsigaltstack\fP(2)), dicha pila se instala.
.IP (1.3)
Diversos fragmentos de contexto relacionados con las señales se guardan en
un marco especial que se crea en la pila. La información guardada incluye:
.RS
.IP \[bu] 3
El registro del contador del programa, es decir la dirección de la siguiente
instrucción del programa principal que debe ejecutarse cuando retorna el
gestor de señales.
.IP \[bu]
El estado del registro específico de la arquitectura, necesario para
reanudar el programa interrumpido.
.IP \[bu]
La máscara de señal actual del hilo;
.IP \[bu]
La configuración de la pila de señales alternativas del hilo.
.RE
.IP
Si el gestor de señales se instaló con el indicador \fBSA_SIGINFO\fP de
\fBsigaction\fP(2), se puede acceder a la información anterior mediante el
objeto \fIucontext_t\fP, al que apunta el tercer argumento del gestor de
señales. Este objeto refleja el estado en el que se entrega la señal, en
lugar de estar en el gestor; por ejemplo, la máscara de señales bloqueadas
almacenada en este objeto no contendrá la máscara de nuevas señales
bloqueadas mediante \fBsigaction\fP(2).
.IP (1.4)
Cualquiera de las señales definidas en \fIact\->sa_mask\fP al registrar el
gestor con \fBsigaction\fP(2) se añaden a la máscara de señal del hilo. La
señal que se entrega también se añade a la máscara de señal, a menos que se
haya definido \fBSA_NODEFER\fP al registrar el controlador. Por lo tanto, estas
señales se bloquean mientras se ejecuta el controlador.
.RE
.IP (2)
El núcleo construye un marco para el controlador de señal en la pila. El
núcleo configura el contador de programa del hilo para que apunte a la
primera instrucción de la función del controlador de señal y la dirección de
retorno de dicha función para que apunte a un fragmento de código en espacio
de usuario conocido como trampolín de señal (descrito en \fBsigreturn\fP(2)).
.IP (3)
El núcleo devuelve el control al espacio de usuario, donde la ejecución
comienza al inicio de la función del controlador de señal.
.IP (4)
Cuando el controlador de señal retorna, el control pasa al código del
trampolín de señal.
.IP (5)
El trampolín de señal llama a \fBsigreturn\fP(2), una llamada al sistema que
utiliza la información del marco de pila creado en el paso 1 para restaurar
el hilo a su estado anterior a la llamada al controlador de señal. La
máscara de señal del hilo y la configuración alternativa de la pila de
señales se restauran como parte de este procedimiento. Al finalizar la
llamada a \fBsigreturn\fP(2), el núcleo transfiere el control de vuelta al
espacio de usuario y el hilo reinicia la ejecución desde el punto donde fue
interrumpido por el gestor de señales.
.P
Tenga en cuenta que si el gestor de señales no retorna (por ejemplo, si el
control se transfiere fuera del gestor mediante \fBsiglongjmp\fP(3) o si el
gestor ejecuta un nuevo programa mediante \fBexecve\fP(2)), el paso final no se
realiza. En particular, en estos casos, es responsabilidad del programador
restaurar el estado de la máscara de señales (mediante \fBsigprocmask\fP(2)) si
se desea desbloquear las señales que se bloquearon al entrar en el gestor de
señales. (Tenga en cuenta que \fBsiglongjmp\fP(3) puede o no restaurar la
máscara de señal, dependiendo del valor de \fIsavesigs\fP especificado en la
llamada correspondiente a \fBsigsetjmp\fP(3).)
.P
.\"
Desde la perspectiva del núcleo, la ejecución del código del gestor de
señales es exactamente igual que la ejecución de cualquier otro código en el
espacio de usuario. Es decir, el núcleo no registra ninguna información de
estado especial que indique que el hilo se está ejecutando dentro de un
gestor de señales. Toda la información de estado necesaria se guarda en los
registros y la pila del espacio de usuario. Por lo tanto, la profundidad con
la que se pueden invocar los gestores de señales anidados está limitada
únicamente por la pila del espacio de usuario (¡y por un diseño de software
sensato!).
.SS "Señales estándar"
Linux admite las señales estándar que se enumeran a continuación. La segunda
columna de la tabla indica qué estándar (si existe) define la señal: «P1990»
indica que la señal se describe en el estándar POSIX.1\-1990 original,
«P2001» indica que la señal se añadió o su definición se modificó en SUSv2 y
POSIX.1\-2001.
.TS
l c c l
____
lB c c l.
Señal	Estándar	Acción	Comentario
SIGABRT	P1990	Core	Señal de cancelación de \f[B]abort\fR(3)
SIGALRM	P1990	Term	Señal del temporizador de \f[B]alarm\fR(2)
SIGBUS	P2001	Core	Error de bus (acceso a memoria inválido)
SIGCHLD	P2001	Ign	Ejecución secundaria detenida, terminada o continuada
SIGCLD	\-	Ign	Sinónimos de \f[B]SIGCHLD\fR
SIGCONT	P1990	Cont.	Continuar si estaba parado
SIGEMT	\-	Term	Emulador de trampa
SIGFPE	P1990	Core	Operación aritmética errónea
SIGHUP	P1990	Term	Cuelgue detectado en la terminal de
			control o muerte del proceso de control
SIGILL	P1990	Core	Instrucción ilegal
SIGINFO	\-		Sinónimos de \f[B]SIGPWR\fR
SIGINT	P1990	Term	Interrupción procedente del teclado
SIGIO	\-	Term	E/S permitida ya (4.2BSD)
SIGIOT	\-	Core	Trampa de IoT. Sinónimos de \f[B]SIGABRT\fR
SIGKILL	P1990	Term	Señal de matar
SIGLOST	\-	Term	Bloqueo de fichero perdido (no usada)
SIGPIPE	P1990	Term	Tubería rota: escritura sin
			Lectores. Consultar \f[B]pipe\fR(7)
SIGPOLL	P2001	Term	Evento que se puede consultar (Sys V);
			Sinónimo de \f[B]SIGIO\fR
SIGPROF	P2001	Term	Ha expirado el reloj de perfilado (profiling)
SIGPWR	\-	Term	Fallo de corriente eléctrica (System V)
SIGQUIT	P1990	Core	Terminación procedente del teclado
SIGSEGV	P1990	Core	Referencia inválida a memoria
SIGSTKFLT	\-	Term	Fallo de la pila en el coprocesador (no usada)
SIGSTOP	P1990	Stop	Parar proceso
SIGTSTP	P1990	Stop	Se ha escrito una parada en el terminal
SIGSYS	P2001	Core	Llamada al sistema incorrecta (SVr4);
			Véase también \f[B]seccomp\fR(2)
SIGTERM	P1990	Term	Señal de terminación
SIGTRAP	P2001	Core	Trampa de traza/punto de ruptura
SIGTTIN	P1990	Stop	Entrada de la terminal para el proceso en segundo plano
SIGTTOU	P1990	Stop	Salida de la terminal para el proceso en segundo plano
SIGUNUSED	\-	Core	Sinónimo de \f[B]SIGSYS\fR
SIGURG	P2001	Ign	Condición urgente en conector (4.2BSD)
SIGUSR1	P1990	Term	Señal definida por usuario 1
SIGUSR2	P1990	Term	Señal definida por usuario 2
SIGVTALRM	P2001	Term	Alarma virtual (4.2BSD)
SIGXCPU	P2001	Core	Límite de tiempo de CPU excedido (4.2BSD);
			Consulte \f[B]setrlimit\fR(2)
SIGXFSZ	P2001	Core	Límite de tamaño de fichero excedido (4.2BSD);
			Consulte \f[B]setrlimit\fR(2)
SIGWINCH	\-	Ign	Señal de reescalado de la ventana (4.3BSD, Sun)
.TE
.P
Las señales \fBSIGKILL\fP y \fBSIGSTOP\fP no pueden ser capturadas, bloqueadas o
ignoradas.
.P
Hasta Linux 2.2 inclusive, el comportamiento predeterminado para \fBSIGSYS\fP,
\fBSIGXCPU\fP, \fBSIGXFSZ\fP y (en arquitecturas distintas de SPARC y MIPS),
\fBSIGBUS\fP era terminar el proceso (sin un volcado de memoria). En otros
sistemas UNIX, la acción predeterminada para \fBSIGXCPU\fP y \fBSIGXFSZ\fP es
finalizar el proceso sin un volcado de memoria. Linux 2.4 cumple con los
requisitos POSIX.1\-2001 para estas señales, por lo que finaliza el proceso
con un volcado de memoria.
.P
\fBSIGEMT\fP no se especifica en POSIX.1\-2001, pero aparece en la mayoría de
los demás sistemas UNIX, donde su acción predeterminada suele ser finalizar
el proceso con un volcado de memoria.
.P
\fBSIGPWR\fP (que no se especifica en POSIX.1\-2001) suele ignorarse por defecto
en los demás sistemas UNIX donde aparece.
.P
.\"
\fBSIGIO\fP (que no se especifica en POSIX.1\-2001) se ignora por defecto en
varios otros sistemas UNIX.
.SS "Semántica de colas y entrega de señales estándar"
Si hay varias señales estándar pendientes para un proceso, no se especifica
el orden de entrega.
.P
.\"
Las señales estándar no se ponen en cola. Si se generan varias instancias de
una señal estándar mientras esta está bloqueada, solo una instancia de la
señal se marca como pendiente (y la señal se entregará solo una vez al
desbloquearse). Si una señal estándar ya está pendiente, la estructura
\fIsiginfo_t\fP (consulte \fBsigaction\fP(2)) asociada a esa señal no se
sobrescribe al llegar instancias posteriores de la misma señal. Por lo
tanto, el proceso recibirá la información asociada a la primera instancia de
la señal.
.SS "Numeración de señales para señales estándar"
El valor numérico de cada señal se muestra en la tabla a continuación. Como
se muestra en la tabla, muchas señales tienen valores numéricos diferentes
en diferentes arquitecturas. El primer valor numérico de cada fila de la
tabla muestra el número de señal en x86, ARM y la mayoría de las demás
arquitecturas; el segundo valor corresponde a Alpha y SPARC; el tercero a
MIPS; y el último a PARISC. Un guion (\-) indica que una señal está ausente
en la arquitectura correspondiente.
.TS
l c c c c l
l c c c c l
______
lB c c c c l.
Señal	x86/ARM	Alpha/	MIPS	PARISC	Notas
	La mayoría de los demás	SPARC
SIGHUP	\01	\01	\01	\01
SIGINT	\02	\02	\02	\02
SIGQUIT	\03	\03	\03	\03
SIGILL	\04	\04	\04	\04
SIGTRAP	\05	\05	\05	\05
SIGABRT	\06	\06	\06	\06
SIGIOT	\06	\06	\06	\06
SIGBUS	\07	10	10	10
SIGEMT	\-	\07	\07	\-
SIGFPE	\08	\08	\08	\08
SIGKILL	\09	\09	\09	\09
SIGUSR1	10	30	16	16
SIGSEGV	11	11	11	11
SIGUSR2	12	31	17	17
SIGPIPE	13	13	13	13
SIGALRM	14	14	14	14
SIGTERM	15	15	15	15
SIGSTKFLT	16	\-	\-	\07
SIGCHLD	17	20	18	18
SIGCLD	\-	\-	18	\-
SIGCONT	18	19	25	26
SIGSTOP	19	17	23	24
SIGTSTP	20	18	24	25
SIGTTIN	21	21	26	27
SIGTTOU	22	22	27	28
SIGURG	23	16	21	29
SIGXCPU	24	24	30	12
SIGXFSZ	25	25	31	30
SIGVTALRM	26	26	28	20
SIGPROF	27	27	29	21
SIGWINCH	28	28	20	23
SIGIO	29	23	22	22
SIGPOLL					Igual que SIGIO
SIGPWR	30	29/\-	19	19
SIGINFO	\-	29/\-	\-	\-
SIGLOST	\-	\-/29	\-	\-
SIGSYS	31	12	12	31
SIGUNUSED	31	\-	\-	31
.TE
.P
Nota:
.IP \[bu] 3
Cuando se define, \fBSIGUNUSED\fP es sinónimo de \fBSIGSYS\fP. Desde glibc 2.26,
\fBSIGUNUSED\fP ya no se define en ninguna arquitectura.
.IP \[bu]
.\"
La señal 29 es \fBSIGINFO\fP/\fBSIGPWR\fP (sinónimos del mismo valor) en Alpha,
pero \fBSIGLOST\fP en SPARC.
.SS "Señales en tiempo real"
A partir de Linux 2.2, Linux admite señales en tiempo real, tal como se
definieron originalmente en las extensiones de tiempo real de POSIX.1b (y
ahora incluidas en POSIX.1\-2001). El rango de señales en tiempo real
admitidas se define mediante las macros \fBSIGRTMIN\fP y
\fBSIGRTMAX\fP. POSIX.1\-2001 requiere que una implementación admita al menos
señales en tiempo real \fB_POSIX_RTSIG_MAX\fP (8).
.P
El kernel de Linux admite un intervalo de 33 señales en tiempo real
diferentes, numeradas del 32 al 64. Sin embargo, la implementación de los
hilos POSIX de glibc utiliza internamente dos (para NPTL) o tres (para
LinuxThreads) señales en tiempo real (véase \fBpthreads\fP(7)) y ajusta el
valor de \fBSIGRTMIN\fP según corresponda (a 34 o 35). Dado que el intervalo de
señales en tiempo real disponibles varía según la implementación de los
hilos de glibc (y esta variación puede ocurrir en tiempo de ejecución según
el núcleo y la glibc disponibles), y de hecho, el rango de señales en tiempo
real varía entre sistemas UNIX, los programas deberían \fInunca referirse a señales en tiempo real utilizando números codificados\fP, sino siempre
referirse a señales en tiempo real utilizando la notación \fBSIGRTMIN\fP+n, e
incluir comprobaciones adecuadas (en tiempo de ejecución) para que
\fBSIGRTMIN\fP+n no exceda \fBSIGRTMAX\fP.
.P
A diferencia de las señales estándar, las señales en tiempo real no tienen
un significado predefinido: el conjunto al completo de señales en tiempo
real puede usarse para propósitos definidos por la aplicación.
.P
La acción por defecto para una señal en tiempo real no manejada es terminar
el proceso receptor.
.P
Las señales en tiempo real se distinguen por lo siguiente:
.IP \[bu] 3
Varias instancias de señales en tiempo real pueden ser puestas en cola. En
contraste, si varias instancias de una señal estándar llegan mientras esa
señal está siendo bloqueada, solamente la primera de ellas es puesta en
cola.
.IP \[bu]
Si la señal se envía usando \fBsigqueue\fP(3), puede enviarse con la señal un
valor (bien un entero o un puntero). Si el proceso receptor establece un
gestor para esta señal usando la bandera \fBSA_SIGINFO\fP en \fBsigaction\fP(2)
puede obtener estos datos a través del campo \fIsi_value\fP de la estructura
\fIsiginfo_t\fP pasada como segundo argumento al gestor. Además, los campos
\fIsi_pid\fP y \fIsi_uid\fP de esta estructura pueden usarse para obtener el
identificador de proceso y el identificador de usuario real del proceso que
envía la señal.
.IP \[bu]
Las señales en tiempo real se entregan en un orden garantizado. Varias
señales en tiempo real del mismo tipo se entregan en el orden en que se
enviaron. Si se envían diferentes señales en tiempo real a un proceso, se
entregan comenzando por la señal con el número más bajo. (Es decir, las
señales con el número más bajo tienen la máxima prioridad). Por el
contrario, si hay varias señales estándar pendientes para un proceso, el
orden de entrega no se especifica.
.P
Si hay señales estándar y en tiempo real pendientes para un proceso, POSIX
deja indefinido cuál es entregada en primer lugar. Linux, como otras muchas
implementaciones, da prioridad a las señales estándar en este caso.
.P
According to POSIX, an implementation should permit at least
\fB_POSIX_SIGQUEUE_MAX\fP (32) real\-time signals to be queued to a process.
However, Linux does things differently.  Up to and including Linux 2.6.7,
Linux imposes a system\-wide limit on the number of queued real\-time signals
for all processes.  This limit can be viewed and (with privilege) changed
via the \fI/proc/sys/kernel/rtsig\-max\fP file.  A related file,
\fI/proc/sys/kernel/rtsig\-nr\fP, can be used to find out how many real\-time
signals are currently queued.  In Linux 2.6.8, these \fI/proc\fP interfaces
were replaced by the \fBRLIMIT_SIGPENDING\fP resource limit, which specifies a
per\-user limit for queued signals; see \fBsetrlimit\fP(2)  for further details.
.P
The addition of real\-time signals required the widening of the signal set
structure (\fIsigset_t\fP)  from 32 to 64 bits.  Consequently, various system
calls were superseded by new system calls that supported the larger signal
sets.  The old and new system calls are as follows:
.TS
lb lb
l l.
Linux 2.0 and earlier	Linux 2.2 and later
\f[B]sigaction\fR(2)	\f[B]rt_sigaction\fR(2)
\f[B]sigpending\fR(2)	\f[B]rt_sigpending\fR(2)
\f[B]sigprocmask\fR(2)	\f[B]rt_sigprocmask\fR(2)
\f[B]sigreturn\fR(2)	\f[B]rt_sigreturn\fR(2)
\f[B]sigsuspend\fR(2)	\f[B]rt_sigsuspend\fR(2)
\f[B]sigtimedwait\fR(2)	\f[B]rt_sigtimedwait\fR(2)
.TE
.\"
.SS "Interruption of system calls and library functions by signal handlers"
If a signal handler is invoked while a system call or library function call
is blocked, then either:
.IP \[bu] 3
the call is automatically restarted after the signal handler returns; or
.IP \[bu]
the call fails with the error \fBEINTR\fP.
.P
Which of these two behaviors occurs depends on the interface and whether or
not the signal handler was established using the \fBSA_RESTART\fP flag (see
\fBsigaction\fP(2)).  The details vary across UNIX systems; below, the details
for Linux.
.P
.\" The following system calls use ERESTARTSYS,
.\" so that they are restartable
If a blocked call to one of the following interfaces is interrupted by a
signal handler, then the call is automatically restarted after the signal
handler returns if the \fBSA_RESTART\fP flag was used; otherwise the call fails
with the error \fBEINTR\fP:
.IP \[bu] 3
\fBread\fP(2), \fBreadv\fP(2), \fBwrite\fP(2), \fBwritev\fP(2), and \fBioctl\fP(2)  calls
on "slow" devices.  A "slow" device is one where the I/O call may block for
an indefinite time, for example, a terminal, pipe, or socket.  If an I/O
call on a slow device has already transferred some data by the time it is
interrupted by a signal handler, then the call will return a success status
(normally, the number of bytes transferred).  Note that a (local) disk is
not a slow device according to this definition; I/O operations on disk
devices are not interrupted by signals.
.IP \[bu]
\fBopen\fP(2), if it can block (e.g., when opening a FIFO; see \fBfifo\fP(7)).
.IP \[bu]
\fBwait\fP(2), \fBwait3\fP(2), \fBwait4\fP(2), \fBwaitid\fP(2) y \fBwaitpid\fP(2).
.IP \[bu]
.\" If a timeout (setsockopt()) is in effect on the socket, then these
.\" system calls switch to using EINTR.  Consequently, they and are not
.\" automatically restarted, and they show the stop/cont behavior
.\" described below.  (Verified from Linux 2.6.26 source, and by experiment; mtk)
.\" FIXME What about sendmmsg()?
Socket interfaces: \fBaccept\fP(2), \fBconnect\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2),
\fBrecvmmsg\fP(2), \fBrecvmsg\fP(2), \fBsend\fP(2), \fBsendto\fP(2), and \fBsendmsg\fP(2),
unless a timeout has been set on the socket (see below).
.IP \[bu]
File locking interfaces: \fBflock\fP(2)  and the \fBF_SETLKW\fP and
\fBF_OFD_SETLKW\fP operations of \fBfcntl\fP(2)
.IP \[bu]
POSIX message queue interfaces: \fBmq_receive\fP(3), \fBmq_timedreceive\fP(3),
\fBmq_send\fP(3), and \fBmq_timedsend\fP(3).
.IP \[bu]
.\" commit 72c1bbf308c75a136803d2d76d0e18258be14c7a
\fBfutex\fP(2)  \fBFUTEX_WAIT\fP (since Linux 2.6.22; beforehand, always failed
with \fBEINTR\fP).
.IP \[bu]
\fBgetrandom\fP(2).
.IP \[bu]
\fBfutex\fP(2)  \fBFUTEX_WAIT_BITSET\fP.
.IP \[bu]
.\" as a consequence of the 2.6.22 changes in the futex() implementation
POSIX semaphore interfaces: \fBsem_wait\fP(3)  and \fBsem_timedwait\fP(3)  (since
Linux 2.6.22; beforehand, always failed with \fBEINTR\fP).
.IP \[bu]
.\" commit 1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06
\fBread\fP(2)  from an \fBinotify\fP(7)  file descriptor (since Linux 3.8;
beforehand, always failed with \fBEINTR\fP).
.P
.\" These are the system calls that give EINTR or ERESTARTNOHAND
.\" on interruption by a signal handler.
The following interfaces are never restarted after being interrupted by a
signal handler, regardless of the use of \fBSA_RESTART\fP; they always fail
with the error \fBEINTR\fP when interrupted by a signal handler:
.IP \[bu] 3
"Input" socket interfaces, when a timeout (\fBSO_RCVTIMEO\fP)  has been set on
the socket using \fBsetsockopt\fP(2): \fBaccept\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2),
\fBrecvmmsg\fP(2)  (also with a non\-NULL \fItimeout\fP argument), and
\fBrecvmsg\fP(2).
.IP \[bu]
.\" FIXME What about sendmmsg()?
"Output" socket interfaces, when a timeout (\fBSO_RCVTIMEO\fP)  has been set on
the socket using \fBsetsockopt\fP(2): \fBconnect\fP(2), \fBsend\fP(2), \fBsendto\fP(2),
and \fBsendmsg\fP(2).
.IP \[bu]
Interfaces used to wait for signals: \fBpause\fP(2), \fBsigsuspend\fP(2),
\fBsigtimedwait\fP(2), and \fBsigwaitinfo\fP(2).
.IP \[bu]
File descriptor multiplexing interfaces: \fBepoll_wait\fP(2),
\fBepoll_pwait\fP(2), \fBpoll\fP(2), \fBppoll\fP(2), \fBselect\fP(2), and \fBpselect\fP(2).
.IP \[bu]
.\" On some other systems, SA_RESTART does restart these system calls
System V IPC interfaces: \fBmsgrcv\fP(2), \fBmsgsnd\fP(2), \fBsemop\fP(2), and
\fBsemtimedop\fP(2).
.IP \[bu]
Sleep interfaces: \fBclock_nanosleep\fP(2), \fBnanosleep\fP(2), and \fBusleep\fP(3).
.IP \[bu]
\fBio_getevents\fP(2).
.P
The \fBsleep\fP(3)  function is also never restarted if interrupted by a
handler, but gives a success return: the number of seconds remaining to
sleep.
.P
.\"
In certain circumstances, the \fBseccomp\fP(2)  user\-space notification feature
can lead to restarting of system calls that would otherwise never be
restarted by \fBSA_RESTART\fP; for details, see \fBseccomp_unotify\fP(2).
.SS "Interruption of system calls and library functions by stop signals"
On Linux, even in the absence of signal handlers, certain blocking
interfaces can fail with the error \fBEINTR\fP after the process is stopped by
one of the stop signals and then resumed via \fBSIGCONT\fP.  This behavior is
not sanctioned by POSIX.1, and doesn't occur on other systems.
.P
The Linux interfaces that display this behavior are:
.IP \[bu] 3
"Input" socket interfaces, when a timeout (\fBSO_RCVTIMEO\fP)  has been set on
the socket using \fBsetsockopt\fP(2): \fBaccept\fP(2), \fBrecv\fP(2), \fBrecvfrom\fP(2),
\fBrecvmmsg\fP(2)  (also with a non\-NULL \fItimeout\fP argument), and
\fBrecvmsg\fP(2).
.IP \[bu]
.\" FIXME What about sendmmsg()?
"Output" socket interfaces, when a timeout (\fBSO_RCVTIMEO\fP)  has been set on
the socket using \fBsetsockopt\fP(2): \fBconnect\fP(2), \fBsend\fP(2), \fBsendto\fP(2),
and \fBsendmsg\fP(2), if a send timeout (\fBSO_SNDTIMEO\fP)  has been set.
.IP \[bu]
\fBepoll_wait\fP(2), \fBepoll_pwait\fP(2).
.IP \[bu]
\fBsemop\fP(2), \fBsemtimedop\fP(2).
.IP \[bu]
\fBsigtimedwait\fP(2), \fBsigwaitinfo\fP(2).
.IP \[bu]
.\" commit 1ca39ab9d21ac93f94b9e3eb364ea9a5cf2aba06
Linux 3.7 and earlier: \fBread\fP(2)  from an \fBinotify\fP(7)  file descriptor
.IP \[bu]
Linux 2.6.21 and earlier: \fBfutex\fP(2)  \fBFUTEX_WAIT\fP, \fBsem_timedwait\fP(3),
\fBsem_wait\fP(3).
.IP \[bu]
Linux 2.6.8 and earlier: \fBmsgrcv\fP(2), \fBmsgsnd\fP(2).
.IP \[bu]
Linux 2.4 and earlier: \fBnanosleep\fP(2).
.SH ESTÁNDARES
POSIX.1, except as noted.
.SH NOTAS
For a discussion of async\-signal\-safe functions, see \fBsignal\-safety\fP(7).
.P
The \fI/proc/\fPpid\fI/task/\fPtid\fI/status\fP file contains various fields that
show the signals that a thread is blocking (\fISigBlk\fP), catching
(\fISigCgt\fP), or ignoring (\fISigIgn\fP).  (The set of signals that are caught
or ignored will be the same across all threads in a process.)  Other fields
show the set of pending signals that are directed to the thread (\fISigPnd\fP)
as well as the set of pending signals that are directed to the process as a
whole (\fIShdPnd\fP).  The corresponding fields in \fI/proc/\fPpid\fI/status\fP show
the information for the main thread.  See \fBproc\fP(5)  for further details.
.SH ERRORES
There are six signals that can be delivered as a consequence of a hardware
exception: \fBSIGBUS\fP, \fBSIGEMT\fP, \fBSIGFPE\fP, \fBSIGILL\fP, \fBSIGSEGV\fP, and
\fBSIGTRAP\fP.  Which of these signals is delivered, for any given hardware
exception, is not documented and does not always make sense.
.P
For example, an invalid memory access that causes delivery of \fBSIGSEGV\fP on
one CPU architecture may cause delivery of \fBSIGBUS\fP on another
architecture, or vice versa.
.P
For another example, using the x86 \fIint\fP instruction with a forbidden
argument (any number other than 3 or 128)  causes delivery of \fBSIGSEGV\fP,
even though \fBSIGILL\fP would make more sense, because of how the CPU reports
the forbidden operation to the kernel.
.SH "VÉASE TAMBIÉN"
\fBkill\fP(1), \fBclone\fP(2), \fBgetrlimit\fP(2), \fBkill\fP(2),
\fBpidfd_send_signal\fP(2), \fBrestart_syscall\fP(2), \fBrt_sigqueueinfo\fP(2),
\fBsetitimer\fP(2), \fBsetrlimit\fP(2), \fBsgetmask\fP(2), \fBsigaction\fP(2),
\fBsigaltstack\fP(2), \fBsignal\fP(2), \fBsignalfd\fP(2), \fBsigpending\fP(2),
\fBsigprocmask\fP(2), \fBsigreturn\fP(2), \fBsigsuspend\fP(2), \fBsigwaitinfo\fP(2),
\fBabort\fP(3), \fBbsd_signal\fP(3), \fBkillpg\fP(3), \fBlongjmp\fP(3),
\fBpthread_sigqueue\fP(3), \fBraise\fP(3), \fBsigqueue\fP(3), \fBsigset\fP(3),
\fBsigsetops\fP(3), \fBsigvec\fP(3), \fBsigwait\fP(3), \fBstrsignal\fP(3),
\fBswapcontext\fP(3), \fBsysv_signal\fP(3), \fBcore\fP(5), \fBproc\fP(5), \fBnptl\fP(7),
\fBpthreads\fP(7), \fBsigevent\fP(3type)
.PP
.SH TRADUCCIÓN
La traducción al español de esta página del manual fue creada por
Miguel Angel Sepulveda <angel@vivaldi.princeton.edu>,
Gerardo Aburruzaga García <gerardo.aburruzaga@uca.es>,
Juan Piernas <piernas@ditec.um.es>,
Miguel Pérez Ibars <mpi79470@alu.um.es>
y
Marcos Fouces <marcos@debian.org>
.
.PP
Esta traducción es documentación libre; lea la
.UR https://www.gnu.org/licenses/gpl-3.0.html
GNU General Public License Version 3
.UE
o posterior con respecto a las condiciones de copyright.
No existe NINGUNA RESPONSABILIDAD.
.PP
Si encuentra algún error en la traducción de esta página del manual, envíe un
correo electrónico a
.MT debian-l10n-spanish@lists.debian.org
.ME .