Pourquoi SIGUSR1 provoque-t-il l'arrêt du processus?

20

J'ai été surpris par ce commentaire dans une autre question:

L'envoi dd du signal USR1 trop tôt après son démarrage (c'est-à-dire dans un script bash, la ligne après l'avoir démarré) le terminera en fait

Quelqu'un peut-il expliquer pourquoi ?

signals Alois Mahdal
la source
Pas tellement une réponse à votre question, mais essayez ce one-liner: { dd if=/dev/zero of=/dev/null & }; kill -USR1 $!; jobs; sleep 1; jobspour reproduire l'effet que vous décrivez.
jippie

Réponses:

38

Chaque signal a une "disposition par défaut" - ce qu'un processus fait par défaut lorsqu'il reçoit ce signal. Il y a un tableau dans la signal(7)page de manuel les énumérant:

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

SIGUSR1et les SIGUSR2deux ont l'action par défaut Term- le processus est terminé. ddenregistre un gestionnaire pour intercepter le signal et faire quelque chose d'utile, mais si vous signalez trop rapidement, il n'a pas encore eu le temps d'enregistrer ce gestionnaire, donc l'action par défaut se produit à la place

Michael Mrozek
la source
1
J'aimerais pouvoir voter deux fois pour avoir été mis au courant de cette obscurité. Voir les processus mourir de façon aléatoire après avoir supprimé un gestionnaire de signal explicite était déconcertant.
DeaconDesperado
1
Existe-t-il un moyen pratique de contrôler cette condition de course au lieu de simplement dormir pendant une durée raisonnable (~ 0,5-1 sec)? (Je veux dire, à côté de quelque chose de ridicule comme capturer et analyser la stracesortie dans un script shell…)
Adrian Günter
J'avais un script shell qui fonctionnait bien. Mais soudain, arrêtez de travailler à cause de probablement!: J'avais hyperthreding maintenant hors tension. Le sous-processus envoyant kill -s SIGUSR1 $ PARENT_PID devient trop rapide maintenant?. Le grand parent pense que le parent se termine normalement, mais le parent exécute toujours la boucle. Ceci est une bonne publication. J'ai passé la majeure partie de la journée à essayer de comprendre cela.
Kemin Zhou