signal(7) Miscellaneous Information Manual signal(7) NOMBRE signal - Breve resumen de la senales DESCRIPCION Linux permite tanto las senales POSIX confiables (de aqui en adelante "senales estandar") como las senales POSIX en tiempo real. Disposiciones de senales Cada senal tiene una disposicion actual, que determina el comportamiento del proceso al recibir la senal. Las entradas de la columna <> de la siguiente tabla definen la disposicion predeterminada para cada senal, como se indica a continuacion: Term La accion por defecto es terminar el proceso. Ign La accion por defecto es ignorar la senal. Core La accion por defecto es terminar el proceso y realizar un volcado de memoria (vea core(5)). Stop La accion por defecto es detener el proceso. Cont. La accion predeterminada es continuar el proceso si esta detenido. Un proceso podra cambiar la disposicion de una senal mediante sigaction(2) o signal(2). (Esta ultima es menos portable al establecer un gestor de senales; consulte signal(2) para obtener mas informacion). Mediante estas llamadas al sistema, un proceso puede elegir que se produzca uno de los siguientes comportamientos al recibir la senal: realizar la accion predeterminada, ignorar la senal o capturarla con un gestor de senal, una funcion definida por el programador que se invoca automaticamente al recibir la senal. Por defecto, un gestor de senales se invoca en la pila de procesos normal. Es posible configurarlo para que utilice una pila alternativa; consulte sigaltstack(2) para obtener informacion sobre como hacerlo y cuando puede ser util. La disposicion de la senal es un atributo por proceso: en una aplicacion multihilo, la disposicion de una senal especifica es la misma para todos los hilos. Un subproceso creado mediante fork(2) hereda una copia de la disposicion de las senales de su subproceso principal. Durante una execve(2), la disposicion de las senales manejadas se restablecera a la predeterminada. La disposicion de las senales ignoradas se mantiene sin cambios. Envio de una senal Las siguientes llamadas al sistema y funciones de biblioteca permiten al llamador enviar una senal: raise(3) Envia una senal al subproceso que realiza la llamada. kill(2) Envia una senal a un proceso especifico, a todos los miembros de un grupo de procesos especifico o a todos los procesos del sistema. pidfd_send_signal(2) Envia una senal a un proceso identificado por un descriptor de archivo PID. killpg(3) Envia una senal a todos los miembros de un grupo concreto de procesos. Envia una senal a un hilo POSIX especifico en el mismo proceso que el invocador. pthread_kill(3) Envia una senal a un hilo concreto dentro de un proceso especifico. (Esta es la llamada al sistema utilizada para implementar pthread_kill(3).) tgkill(2) Envia una senal a un hilo en concreto dentro de un proceso especifico. Esta es la llamada al sistema utilizada para implementar pthread_kill(3). sigqueue(3) Envia una senal en tiempo real con los datos correspondientes a un proceso especifico. Esperando a que se capture una senal Las siguientes llamadas al sistema suspenden la ejecucion del hilo invocador hasta que se capture una senal (o una senal no controlada finalice el proceso): pause(2) Suspende la ejecucion hasta que se capture alguna senal. sigsuspend(2) Cambia temporalmente la mascara de la senal (vease mas adelante) y suspende la ejecucion hasta que se capture una de las senales no enmascaradas. Aceptar una senal sincronicamente En lugar de capturar una senal asincronicamente mediante un gestor de senales, es posible aceptar la senal sincronicamente; es decir, bloquear la ejecucion hasta que se entregue la senal, momento en el que el nucleo devuelve informacion sobre la senal al invocador. En general hay dos formas de hacerlo: o sigwaitinfo(2), sigtimedwait(2) y sigwait(3) suspenden la ejecucion hasta que se entrega una de las senales de un conjunto dado. Cada una de estas llamadas retorna informacion sobre la senal entregada. o signalfd(2) devuelve un descriptor de archivo que permite leer informacion sobre las senales entregadas al llamante. Cada read(2) de este descriptor de archivo se bloquea hasta que se entrega al llamante una de las senales del conjunto especificado en la llamada signalfd(2). El bufer devuelto por read(2) contiene una estructura que describe la senal. Mascara de senal y senales pendientes Una senal puede estar bloqueada, lo que significa que no se entregara hasta que se desbloquee posteriormente. Entre su generacion y su entrega, se dice que una senal esta pendiente. Cada hilo de un proceso tiene una mascara de senal independiente, que indica el conjunto de senales que el hilo esta bloqueando actualmente. Un hilo puede manipular su mascara de senal mediante pthread_sigmask(3). En una aplicacion tradicional de un solo hilo, se puede usar sigprocmask(2) para manipular la mascara de senal. Un hilo hijo creado mediante fork(2) hereda una copia de la mascara de senal de su padre; la mascara de senal se conserva en execve(2). Una senal puede estar dirigida al proceso o al hilo. Una senal dirigida al proceso es aquella que esta dirigida al proceso en su conjunto (y, por lo tanto, pendiente de el). Una senal puede estar dirigida al proceso porque fue generada por el nucleo por razones distintas a una excepcion de hardware, o porque se envio mediante kill(2) o sigqueue(3). Una senal dirigida al hilo es aquella que esta dirigida a un hilo especifico. Una senal puede estar dirigida a un hilo porque se genero como consecuencia de la ejecucion de una instruccion especifica en lenguaje de maquina que activo una excepcion de hardware (por ejemplo, SIGSEGV para un acceso a memoria no valido o SIGFPE para un error matematico) o porque se dirigio a un hilo especifico que utilizaba interfaces como tgkill(2) o pthread_kill(3). Se puede enviar una senal dirigida por el proceso a cualquiera de los hilos que no la tengan bloqueada. Si mas de un hilo tiene la senal liberada, el nucleo elige un hilo arbitrario al que enviar la senal. Un hilo puede obtener el conjunto de senales pendientes mediante sigping(2). Este conjunto consistira en la union del conjunto de senales pendientes dirigidas por el proceso y el conjunto de senales pendientes para el hilo que realiza la llamada. Un hilo hijo creado mediante fork(2) inicialmente tiene un conjunto de senales pendientes vacio. Este conjunto se conserva en un execve(2). Ejecucion de gestores de senales Siempre que se produce una transicion del modo nucleo a la ejecucion en modo usuario (por ejemplo, al regresar de una llamada al sistema o al programar un hilo en la CPU), el nucleo comprueba si hay una senal pendiente desbloqueada para la cual el proceso haya establecido un gestor de senales. Si existe dicha senal pendiente, se producen los siguientes pasos: (1) El nucleo realiza los pasos preparatorios necesarios para la ejecucion del gestor de senales: (1.1) La senal se elimina del conjunto de senales pendientes. (1.2) Si el gestor de senales se instalo mediante una llamada a sigaction(2) que definio el indicador SA_ONSTACK y el hilo ha definido una pila de senales alternativa (mediante sigaltstack(2)), dicha pila se instala. (1.3) Diversos fragmentos de contexto relacionados con las senales se guardan en un marco especial que se crea en la pila. La informacion guardada incluye: o El registro del contador del programa, es decir la direccion de la siguiente instruccion del programa principal que debe ejecutarse cuando retorna el gestor de senales. o El estado del registro especifico de la arquitectura, necesario para reanudar el programa interrumpido. o La mascara de senal actual del hilo; o La configuracion de la pila de senales alternativas del hilo. Si el gestor de senales se instalo con el indicador SA_SIGINFO de sigaction(2), se puede acceder a la informacion anterior mediante el objeto ucontext_t, al que apunta el tercer argumento del gestor de senales. Este objeto refleja el estado en el que se entrega la senal, en lugar de estar en el gestor; por ejemplo, la mascara de senales bloqueadas almacenada en este objeto no contendra la mascara de nuevas senales bloqueadas mediante sigaction(2). (1.4) Cualquiera de las senales definidas en act->sa_mask al registrar el gestor con sigaction(2) se anaden a la mascara de senal del hilo. La senal que se entrega tambien se anade a la mascara de senal, a menos que se haya definido SA_NODEFER al registrar el controlador. Por lo tanto, estas senales se bloquean mientras se ejecuta el controlador. (2) El nucleo construye un marco para el controlador de senal en la pila. El nucleo configura el contador de programa del hilo para que apunte a la primera instruccion de la funcion del controlador de senal y la direccion de retorno de dicha funcion para que apunte a un fragmento de codigo en espacio de usuario conocido como trampolin de senal (descrito en sigreturn(2)). (3) El nucleo devuelve el control al espacio de usuario, donde la ejecucion comienza al inicio de la funcion del controlador de senal. (4) Cuando el controlador de senal retorna, el control pasa al codigo del trampolin de senal. (5) El trampolin de senal llama a sigreturn(2), una llamada al sistema que utiliza la informacion del marco de pila creado en el paso 1 para restaurar el hilo a su estado anterior a la llamada al controlador de senal. La mascara de senal del hilo y la configuracion alternativa de la pila de senales se restauran como parte de este procedimiento. Al finalizar la llamada a sigreturn(2), el nucleo transfiere el control de vuelta al espacio de usuario y el hilo reinicia la ejecucion desde el punto donde fue interrumpido por el gestor de senales. Tenga en cuenta que si el gestor de senales 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 mascara de senales (mediante sigprocmask(2)) si se desea desbloquear las senales que se bloquearon al entrar en el gestor de senales. (Tenga en cuenta que siglongjmp(3) puede o no restaurar la mascara de senal, dependiendo del valor de savesigs especificado en la llamada correspondiente a sigsetjmp(3).) Desde la perspectiva del nucleo, la ejecucion del codigo del gestor de senales es exactamente igual que la ejecucion de cualquier otro codigo en el espacio de usuario. Es decir, el nucleo no registra ninguna informacion de estado especial que indique que el hilo se esta ejecutando dentro de un gestor de senales. Toda la informacion 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 senales anidados esta limitada unicamente por la pila del espacio de usuario (!y por un diseno de software sensato!). Senales estandar Linux admite las senales estandar que se enumeran a continuacion. La segunda columna de la tabla indica que estandar (si existe) define la senal: <> indica que la senal se describe en el estandar POSIX.1-1990 original, <> indica que la senal se anadio o su definicion se modifico en SUSv2 y POSIX.1-2001. Senal Estandar Accion Comentario -------------------------------------------------------------------------------------------- SIGABRT P1990 Core Senal de cancelacion de abort(3) SIGALRM P1990 Term Senal del temporizador de alarm(2) SIGBUS P2001 Core Error de bus (acceso a memoria invalido) SIGCHLD P2001 Ign Ejecucion secundaria detenida, terminada o continuada SIGCLD - Ign Sinonimos de SIGCHLD SIGCONT P1990 Cont. Continuar si estaba parado SIGEMT - Term Emulador de trampa SIGFPE P1990 Core Operacion aritmetica erronea SIGHUP P1990 Term Cuelgue detectado en la terminal de control o muerte del proceso de control SIGILL P1990 Core Instruccion ilegal SIGINFO - Sinonimos de SIGPWR SIGINT P1990 Term Interrupcion procedente del teclado SIGIO - Term E/S permitida ya (4.2BSD) SIGIOT - Core Trampa de IoT. Sinonimos de SIGABRT SIGKILL P1990 Term Senal de matar SIGLOST - Term Bloqueo de fichero perdido (no usada) SIGPIPE P1990 Term Tuberia rota: escritura sin Lectores. Consultar pipe(7) SIGPOLL P2001 Term Evento que se puede consultar (Sys V); Sinonimo de SIGIO SIGPROF P2001 Term Ha expirado el reloj de perfilado (profiling) SIGPWR - Term Fallo de corriente electrica (System V) SIGQUIT P1990 Core Terminacion procedente del teclado SIGSEGV P1990 Core Referencia invalida 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); Vease tambien seccomp(2) SIGTERM P1990 Term Senal de terminacion 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 Sinonimo de SIGSYS SIGURG P2001 Ign Condicion urgente en conector (4.2BSD) SIGUSR1 P1990 Term Senal definida por usuario 1 SIGUSR2 P1990 Term Senal definida por usuario 2 SIGVTALRM P2001 Term Alarma virtual (4.2BSD) SIGXCPU P2001 Core Limite de tiempo de CPU excedido (4.2BSD); Consulte setrlimit(2) SIGXFSZ P2001 Core Limite de tamano de fichero excedido (4.2BSD); Consulte setrlimit(2) SIGWINCH - Ign Senal de reescalado de la ventana (4.3BSD, Sun) Las senales 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 accion 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 senales, por lo que finaliza el proceso con un volcado de memoria. SIGEMT no se especifica en POSIX.1-2001, pero aparece en la mayoria de los demas sistemas UNIX, donde su accion 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 demas sistemas UNIX donde aparece. SIGIO (que no se especifica en POSIX.1-2001) se ignora por defecto en varios otros sistemas UNIX. Semantica de colas y entrega de senales estandar Si hay varias senales estandar pendientes para un proceso, no se especifica el orden de entrega. Las senales estandar no se ponen en cola. Si se generan varias instancias de una senal estandar mientras esta esta bloqueada, solo una instancia de la senal se marca como pendiente (y la senal se entregara solo una vez al desbloquearse). Si una senal estandar ya esta pendiente, la estructura siginfo_t (consulte sigaction(2)) asociada a esa senal no se sobrescribe al llegar instancias posteriores de la misma senal. Por lo tanto, el proceso recibira la informacion asociada a la primera instancia de la senal. Numeracion de senales para senales estandar El valor numerico de cada senal se muestra en la tabla a continuacion. Como se muestra en la tabla, muchas senales tienen valores numericos diferentes en diferentes arquitecturas. El primer valor numerico de cada fila de la tabla muestra el numero de senal en x86, ARM y la mayoria de las demas arquitecturas; el segundo valor corresponde a Alpha y SPARC; el tercero a MIPS; y el ultimo a PARISC. Un guion (-) indica que una senal esta ausente en la arquitectura correspondiente. Senal x86/ARM Alpha/ MIPS PARISC Notas La mayoria de los demas SPARC ----------------------------------------------------------------------------------- SIGHUP 1 1 1 1 SIGINT 2 2 2 2 SIGQUIT 3 3 3 3 SIGILL 4 4 4 4 SIGTRAP 5 5 5 5 SIGABRT 6 6 6 6 SIGIOT 6 6 6 6 SIGBUS 7 10 10 10 SIGEMT - 7 7 - SIGFPE 8 8 8 8 SIGKILL 9 9 9 9 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 - - 7 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 Nota: o Cuando se define, SIGUNUSED es sinonimo de SIGSYS. Desde glibc 2.26, SIGUNUSED ya no se define en ninguna arquitectura. o La senal 29 es SIGINFO/SIGPWR (sinonimos del mismo valor) en Alpha, pero SIGLOST en SPARC. Senales en tiempo real A partir de Linux 2.2, Linux admite senales 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 senales en tiempo real admitidas se define mediante las macros SIGRTMIN y SIGRTMAX. POSIX.1-2001 requiere que una implementacion admita al menos senales en tiempo real _POSIX_RTSIG_MAX (8). El kernel de Linux admite un intervalo de 33 senales en tiempo real diferentes, numeradas del 32 al 64. Sin embargo, la implementacion de los hilos POSIX de glibc utiliza internamente dos (para NPTL) o tres (para LinuxThreads) senales en tiempo real (vease pthreads(7)) y ajusta el valor de SIGRTMIN segun corresponda (a 34 o 35). Dado que el intervalo de senales en tiempo real disponibles varia segun la implementacion de los hilos de glibc (y esta variacion puede ocurrir en tiempo de ejecucion segun el nucleo y la glibc disponibles), y de hecho, el rango de senales en tiempo real varia entre sistemas UNIX, los programas deberian nunca referirse a senales en tiempo real utilizando numeros codificados, sino siempre referirse a senales en tiempo real utilizando la notacion SIGRTMIN+n, e incluir comprobaciones adecuadas (en tiempo de ejecucion) para que SIGRTMIN+n no exceda SIGRTMAX. A diferencia de las senales estandar, las senales en tiempo real no tienen un significado predefinido: el conjunto al completo de senales en tiempo real puede usarse para propositos definidos por la aplicacion. La accion por defecto para una senal en tiempo real no manejada es terminar el proceso receptor. Las senales en tiempo real se distinguen por lo siguiente: o Varias instancias de senales en tiempo real pueden ser puestas en cola. En contraste, si varias instancias de una senal estandar llegan mientras esa senal esta siendo bloqueada, solamente la primera de ellas es puesta en cola. o Si la senal se envia usando sigqueue(3), puede enviarse con la senal un valor (bien un entero o un puntero). Si el proceso receptor establece un gestor para esta senal usando la bandera SA_SIGINFO en sigaction(2) puede obtener estos datos a traves del campo si_value de la estructura siginfo_t pasada como segundo argumento al gestor. Ademas, 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 envia la senal. o Las senales en tiempo real se entregan en un orden garantizado. Varias senales en tiempo real del mismo tipo se entregan en el orden en que se enviaron. Si se envian diferentes senales en tiempo real a un proceso, se entregan comenzando por la senal con el numero mas bajo. (Es decir, las senales con el numero mas bajo tienen la maxima prioridad). Por el contrario, si hay varias senales estandar pendientes para un proceso, el orden de entrega no se especifica. Si hay senales estandar y en tiempo real pendientes para un proceso, POSIX deja indefinido cual es entregada en primer lugar. Linux, como otras muchas implementaciones, da prioridad a las senales estandar 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: Linux 2.0 and earlier Linux 2.2 and later sigaction(2) rt_sigaction(2) sigpending(2) rt_sigpending(2) sigprocmask(2) rt_sigprocmask(2) sigreturn(2) rt_sigreturn(2) sigsuspend(2) rt_sigsuspend(2) sigtimedwait(2) rt_sigtimedwait(2) 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: o the call is automatically restarted after the signal handler returns; or o 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: o 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. o open(2), if it can block (e.g., when opening a FIFO; see fifo(7)). o wait(2), wait3(2), wait4(2), waitid(2) y waitpid(2). o 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). o File locking interfaces: flock(2) and the F_SETLKW and F_OFD_SETLKW operations of fcntl(2) o POSIX message queue interfaces: mq_receive(3), mq_timedreceive(3), mq_send(3), and mq_timedsend(3). o futex(2) FUTEX_WAIT (since Linux 2.6.22; beforehand, always failed with EINTR). o getrandom(2). o futex(2) FUTEX_WAIT_BITSET. o POSIX semaphore interfaces: sem_wait(3) and sem_timedwait(3) (since Linux 2.6.22; beforehand, always failed with EINTR). o 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: o "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). o "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). o Interfaces used to wait for signals: pause(2), sigsuspend(2), sigtimedwait(2), and sigwaitinfo(2). o File descriptor multiplexing interfaces: epoll_wait(2), epoll_pwait(2), poll(2), ppoll(2), select(2), and pselect(2). o System V IPC interfaces: msgrcv(2), msgsnd(2), semop(2), and semtimedop(2). o Sleep interfaces: clock_nanosleep(2), nanosleep(2), and usleep(3). o 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: o "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). o "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. o epoll_wait(2), epoll_pwait(2). o semop(2), semtimedop(2). o sigtimedwait(2), sigwaitinfo(2). o Linux 3.7 and earlier: read(2) from an inotify(7) file descriptor o Linux 2.6.21 and earlier: futex(2) FUTEX_WAIT, sem_timedwait(3), sem_wait(3). o Linux 2.6.8 and earlier: msgrcv(2), msgsnd(2). o Linux 2.4 and earlier: nanosleep(2). ESTANDARES POSIX.1, except as noted. NOTAS For a discussion of async-signal-safe functions, see signal-safety(7). The /proc/pid/task/tid/status file contains various fields that show the signals that a thread is blocking (SigBlk), catching (SigCgt), or ignoring (SigIgn). (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 (SigPnd) as well as the set of pending signals that are directed to the process as a whole (ShdPnd). The corresponding fields in /proc/pid/status show the information for the main thread. See proc(5) for further details. ERRORES There are six signals that can be delivered as a consequence of a hardware exception: SIGBUS, SIGEMT, SIGFPE, SIGILL, SIGSEGV, and SIGTRAP. Which of these signals is delivered, for any given hardware exception, is not documented and does not always make sense. For example, an invalid memory access that causes delivery of SIGSEGV on one CPU architecture may cause delivery of SIGBUS on another architecture, or vice versa. For another example, using the x86 int instruction with a forbidden argument (any number other than 3 or 128) causes delivery of SIGSEGV, even though SIGILL would make more sense, because of how the CPU reports the forbidden operation to the kernel. VEASE TAMBIEN kill(1), clone(2), getrlimit(2), kill(2), pidfd_send_signal(2), restart_syscall(2), rt_sigqueueinfo(2), setitimer(2), setrlimit(2), sgetmask(2), sigaction(2), sigaltstack(2), signal(2), signalfd(2), sigpending(2), sigprocmask(2), sigreturn(2), sigsuspend(2), sigwaitinfo(2), abort(3), bsd_signal(3), killpg(3), longjmp(3), pthread_sigqueue(3), raise(3), sigqueue(3), sigset(3), sigsetops(3), sigvec(3), sigwait(3), strsignal(3), swapcontext(3), sysv_signal(3), core(5), proc(5), nptl(7), pthreads(7), sigevent(3type) TRADUCCION La traduccion al espanol de esta pagina del manual fue creada por Miguel Angel Sepulveda , Gerardo Aburruzaga Garcia , Juan Piernas , Miguel Perez Ibars y Marcos Fouces Esta traduccion es documentacion libre; lea la GNU General Public License Version 3 o posterior con respecto a las condiciones de copyright. No existe NINGUNA RESPONSABILIDAD. Si encuentra algun error en la traduccion de esta pagina del manual, envie un correo electronico a . Paginas de Manual de Linux 6.15 17 Mayo 2025 signal(7)