¿Por qué SIGUSR1 hace que el proceso finalice?

20

Me sorprendió este comentario en otra pregunta:

Enviar dd la señal USR1 demasiado pronto después de que haya comenzado (es decir, en un script bash, la línea después de que la haya iniciado), de hecho, la terminará

¿Alguien puede explicar por qué ?

signals Alois Mahdal
fuente
No es tanto una respuesta a tu pregunta, pero prueba esta frase: { dd if=/dev/zero of=/dev/null & }; kill -USR1 $!; jobs; sleep 1; jobspara reproducir el efecto que estás describiendo.
jippie

Respuestas:

38

Cada señal tiene una "disposición predeterminada": lo que hace un proceso por defecto cuando recibe esa señal. Hay una tabla en la signal(7)página del manual que los enumera:

Signal     Value     Action   Comment
──────────────────────────────────────────────────────────────────────
...
SIGUSR1   30,10,16    Term    User-defined signal 1
SIGUSR2   31,12,17    Term    User-defined signal 2

SIGUSR1y SIGUSR2ambos tienen la acción predeterminada Term: el proceso finaliza. ddregistra un controlador para interceptar la señal y hacer algo útil con ella, pero si señaliza demasiado rápido aún no ha tenido tiempo de registrar ese controlador, por lo que la acción predeterminada ocurre en su lugar

Michael Mrozek
fuente
1
Desearía poder votar dos veces por estar al tanto de esta oscuridad. Ver procesos morir aleatoriamente después de eliminar un controlador de señal explícito fue desconcertante.
DeaconDesperado
1
¿Hay alguna forma práctica de controlar esta condición de carrera en lugar de simplemente dormir durante un período de tiempo razonable (~ 0.5-1 seg)? (Quiero decir, junto a algo ridículo como capturar y analizar la stracesalida en un script de shell ...)
Adrian Günter
Tenía un script de shell funcionando bien. Pero, de repente, ¡dejé de trabajar por lo más probable! ¿El subproceso que envía kill -s SIGUSR1 $ PARENT_PID se vuelve demasiado rápido ahora? El padre principal piensa que el padre finaliza normalmente, pero el padre todavía está ejecutando el ciclo. Esta es una buena publicación. He pasado la mayor parte del día tratando de resolver esto.
Kemin Zhou