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
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
stracesortie dans un script shell…)
{ dd if=/dev/zero of=/dev/null & }; kill -USR1 $!; jobs; sleep 1; jobspour reproduire l'effet que vous décrivez.