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 ?
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 ?
Réponses:
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
SIGUSR1
et les SIGUSR2
deux ont l'action par défaut Term
- le processus est terminé. dd
enregistre 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
strace
sortie dans un script shell…)
{ dd if=/dev/zero of=/dev/null & }; kill -USR1 $!; jobs; sleep 1; jobs
pour reproduire l'effet que vous décrivez.