Disposiciones de señales¶

Cada señal tiene una disposición actual, que determina el comportamiento del proceso al recibir la señal.

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:

Term

La acción por defecto es terminar el proceso.

Ign

La acción por defecto es ignorar la señal.

Core

La acción por defecto es terminar el proceso y realizar un volcado de memoria (vea core(5)).

Stop

La acción por defecto es detener el proceso.

Cont.

La acción predeterminada es continuar el proceso si está detenido.

Un proceso podrá cambiar la disposición de una señal mediante sigaction(2) o signal(2). (Esta última es menos portable al establecer un gestor de señales; consulte signal(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 gestor de señal, una función definida por el programador que se invoca automáticamente al recibir la señal.

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 sigaltstack(2) para obtener información sobre cómo hacerlo y cuándo puede ser útil.

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.

Un subproceso creado mediante fork(2) hereda una copia de la disposición de las señales de su subproceso principal. Durante una execve(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.

Envío de una señal¶

Las siguientes llamadas al sistema y funciones de biblioteca permiten al llamador enviar una señal:

raise(3)

Envía una señal al subproceso que realiza la llamada.

kill(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.

pidfd_send_signal(2)

Envía una señal a un proceso identificado por un descriptor de archivo PID.

killpg(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.

pthread_kill(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 pthread_kill(3).)

tgkill(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 pthread_kill(3).

sigqueue(3)

Envía una señal en tiempo real con los datos correspondientes a un proceso específico.

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):

pause(2)

Suspende la ejecución hasta que se capture alguna señal.

sigsuspend(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.

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:

•

sigwaitinfo(2), sigtimedwait(2) y sigwait(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.

•

signalfd(2) devuelve un descriptor de archivo que permite leer información sobre las señales entregadas al llamante. Cada read(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 signalfd(2). El búfer devuelto por read(2) contiene una estructura que describe la señal.

Máscara de señal y señales pendientes¶

Una señal puede estar bloqueada, 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á pendiente.

Cada hilo de un proceso tiene una máscara de señal 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 pthread_sigmask(3). En una aplicación tradicional de un solo hilo, se puede usar sigprocmask(2) para manipular la máscara de señal.

Un hilo hijo creado mediante fork(2) hereda una copia de la máscara de señal de su padre; la máscara de señal se conserva en execve(2).

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 kill(2) o sigqueue(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, SIGSEGV para un acceso a memoria no válido o SIGFPE para un error matemático) o porque se dirigió a un hilo específico que utilizaba interfaces como tgkill(2) o pthread_kill(3).

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.

Un hilo puede obtener el conjunto de señales pendientes mediante sigping(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.

Un hilo hijo creado mediante fork(2) inicialmente tiene un conjunto de señales pendientes vacío. Este conjunto se conserva en un execve(2).

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:

(1)

El núcleo realiza los pasos preparatorios necesarios para la ejecución del gestor de señales:

(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 sigreturn(2)).

(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.

(4)

Cuando el controlador de señal retorna, el control pasa al código del trampolín de señal.

(5)

El trampolín de señal llama a sigreturn(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 sigreturn(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.

Tenga en cuenta que si el gestor de señales no retorna (por ejemplo, si el control se transfiere fuera del gestor mediante siglongjmp(3) o si el gestor ejecuta un nuevo programa mediante execve(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 sigprocmask(2)) si se desea desbloquear las señales que se bloquearon al entrar en el gestor de señales. (Tenga en cuenta que siglongjmp(3) puede o no restaurar la máscara de señal, dependiendo del valor de savesigs especificado en la llamada correspondiente a sigsetjmp(3).)

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!).

Señales estándar¶

Linux supports the standard signals listed below. The second column of the table indicates which standard (if any) specified the signal: "P1990" indicates that the signal is described in the original POSIX.1-1990 standard; "P2001" indicates that the signal was added in SUSv2 and POSIX.1-2001.

Las señales SIGKILL y SIGSTOP no pueden ser capturadas, bloqueadas o ignoradas.

Hasta Linux 2.2 inclusive, el comportamiento predeterminado para SIGSYS, SIGXCPU, SIGXFSZ y (en arquitecturas distintas de SPARC y MIPS), SIGBUS era terminar el proceso (sin un volcado de memoria). En otros sistemas UNIX, la acción predeterminada para SIGXCPU y SIGXFSZ 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.

SIGEMT 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.

SIGPWR (que no se especifica en POSIX.1-2001) suele ignorarse por defecto en los demás sistemas UNIX donde aparece.

SIGIO (que no se especifica en POSIX.1-2001) se ignora por defecto en varios otros sistemas UNIX.

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.

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 siginfo_t (consulte sigaction(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.

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.

Nota:

•

Cuando se define, SIGUNUSED es sinónimo de SIGSYS. Desde glibc 2.26, SIGUNUSED ya no se define en ninguna arquitectura.

•

La señal 29 es SIGINFO/SIGPWR (sinónimos del mismo valor) en Alpha, pero SIGLOST en SPARC.

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 SIGRTMIN y SIGRTMAX. POSIX.1-2001 requiere que una implementación admita al menos señales en tiempo real _POSIX_RTSIG_MAX (8).

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 pthreads(7)) y ajusta el valor de SIGRTMIN 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 nunca referirse a señales en tiempo real utilizando números codificados, sino siempre referirse a señales en tiempo real utilizando la notación SIGRTMIN+n, e incluir comprobaciones adecuadas (en tiempo de ejecución) para que SIGRTMIN+n no exceda SIGRTMAX.

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.

La acción por defecto para una señal en tiempo real no manejada es terminar el proceso receptor.

Las señales en tiempo real se distinguen por lo siguiente:

•

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.

•

Si la señal se envía usando sigqueue(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 SA_SIGINFO en sigaction(2) puede obtener estos datos a través del campo si_value de la estructura siginfo_t pasada como segundo argumento al gestor. Además, los campos si_pid y si_uid 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.

•

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.

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.

According to POSIX, an implementation should permit at least _POSIX_SIGQUEUE_MAX (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 /proc/sys/kernel/rtsig-max file. A related file, /proc/sys/kernel/rtsig-nr, can be used to find out how many real-time signals are currently queued. In Linux 2.6.8, these /proc interfaces were replaced by the RLIMIT_SIGPENDING resource limit, which specifies a per-user limit for queued signals; see setrlimit(2) for further details.

The addition of real-time signals required the widening of the signal set structure (sigset_t) 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:

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:

•

the call is automatically restarted after the signal handler returns; or

•

the call fails with the error EINTR.

Which of these two behaviors occurs depends on the interface and whether or not the signal handler was established using the SA_RESTART flag (see sigaction(2)). The details vary across UNIX systems; below, the details for Linux.

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 SA_RESTART flag was used; otherwise the call fails with the error EINTR:

•

read(2), readv(2), write(2), writev(2), and ioctl(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.

•

open(2), if it can block (e.g., when opening a FIFO; see fifo(7)).

•

wait(2), wait3(2), wait4(2), waitid(2) y waitpid(2).

•

Socket interfaces: accept(2), connect(2), recv(2), recvfrom(2), recvmmsg(2), recvmsg(2), send(2), sendto(2), and sendmsg(2), unless a timeout has been set on the socket (see below).

•

File locking interfaces: flock(2) and the F_SETLKW and F_OFD_SETLKW operations of fcntl(2)

•

POSIX message queue interfaces: mq_receive(3), mq_timedreceive(3), mq_send(3), and mq_timedsend(3).

•

futex(2) FUTEX_WAIT (since Linux 2.6.22; beforehand, always failed with EINTR).

•

getrandom(2).

•

pthread_mutex_lock(3), pthread_cond_wait(3), and related APIs.

•

futex(2) FUTEX_WAIT_BITSET.

•

POSIX semaphore interfaces: sem_wait(3) and sem_timedwait(3) (since Linux 2.6.22; beforehand, always failed with EINTR).

•

read(2) from an inotify(7) file descriptor (since Linux 3.8; beforehand, always failed with EINTR).

The following interfaces are never restarted after being interrupted by a signal handler, regardless of the use of SA_RESTART; they always fail with the error EINTR when interrupted by a signal handler:

•

"Input" socket interfaces, when a timeout (SO_RCVTIMEO) has been set on the socket using setsockopt(2): accept(2), recv(2), recvfrom(2), recvmmsg(2) (also with a non-NULL timeout argument), and recvmsg(2).

•

"Output" socket interfaces, when a timeout (SO_RCVTIMEO) has been set on the socket using setsockopt(2): connect(2), send(2), sendto(2), and sendmsg(2).

•

Interfaces used to wait for signals: pause(2), sigsuspend(2), sigtimedwait(2), and sigwaitinfo(2).

•

File descriptor multiplexing interfaces: epoll_wait(2), epoll_pwait(2), poll(2), ppoll(2), select(2), and pselect(2).

•

System V IPC interfaces: msgrcv(2), msgsnd(2), semop(2), and semtimedop(2).

•

Sleep interfaces: clock_nanosleep(2), nanosleep(2), and usleep(3).

•

io_getevents(2).

The sleep(3) function is also never restarted if interrupted by a handler, but gives a success return: the number of seconds remaining to sleep.

In certain circumstances, the seccomp(2) user-space notification feature can lead to restarting of system calls that would otherwise never be restarted by SA_RESTART; for details, see seccomp_unotify(2).

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 EINTR after the process is stopped by one of the stop signals and then resumed via SIGCONT. This behavior is not sanctioned by POSIX.1, and doesn't occur on other systems.

The Linux interfaces that display this behavior are:

•

"Input" socket interfaces, when a timeout (SO_RCVTIMEO) has been set on the socket using setsockopt(2): accept(2), recv(2), recvfrom(2), recvmmsg(2) (also with a non-NULL timeout argument), and recvmsg(2).

•

"Output" socket interfaces, when a timeout (SO_RCVTIMEO) has been set on the socket using setsockopt(2): connect(2), send(2), sendto(2), and sendmsg(2), if a send timeout (SO_SNDTIMEO) has been set.

•

epoll_wait(2), epoll_pwait(2).

•

semop(2), semtimedop(2).

•

sigtimedwait(2), sigwaitinfo(2).

•

Linux 3.7 and earlier: read(2) from an inotify(7) file descriptor

•

Linux 2.6.21 and earlier: futex(2) FUTEX_WAIT, sem_timedwait(3), sem_wait(3).

•

Linux 2.6.8 and earlier: msgrcv(2), msgsnd(2).

•

Linux 2.4 and earlier: nanosleep(2).