Pourquoi de nombreux programmes Unix utilisent-ils des signaux comme USR1?
De nombreux programmes Unix acceptent des signaux comme USR1 et USR2. Par exemple, pour mettre à niveau l'exécutable pour Nginx à la volée, vous envoyez kill -USR2.
Je comprends que USR1 est un signal "défini par l'utilisateur", ce qui signifie que celui qui a créé le programme peut l'utiliser pour signifier "arrêter" ou "vider vos journaux" ou "imprimer foo mille fois" ou autre chose. Mais je ne comprends pas pourquoi ils doivent utiliser ce nom arbitraire. Pourquoi pas kill -UPGRADE, ou kill -GRACEFUL_SHUTDOWN? Unix autorise-t-il uniquement des signaux spécifiques?
Pendant que nous y sommes, Nginx utilise également les signaux suivants (voir documentation ):
- TERM, INT : arrêt rapide
- [~ # ~] quitter [~ # ~] : arrêt progressif
- [~ # ~] hup [~ # ~] :
- Recharger la configuration
- Démarrer les nouveaux processus de travail avec une nouvelle configuration
- Arrêtez gracieusement les anciens processus de travail
- USR1 : Rouvrez les fichiers journaux
- USR2 : mise à niveau exécutable à la volée
- [~ # ~] treuil [~ # ~] : arrêt progressif des processus de travail
HUP? TREUIL? Quelle est la raison de ces noms? Où puis-je en savoir plus à ce sujet?
Les signaux disponibles sur un OS sont définis par l'OS (généralement après POSIX) - ce ne sont pas des "chaînes" mais plutôt des constantes entières avec des noms standard. USR1 et USR2 sont les deux signaux qui n'ont pas de signification spécifique attachée - destinés à toute utilisation arbitraire souhaitée par le développeur.
Sur votre machine Linux, lisez man 7 signal pour un aperçu de la gestion du signal et des signaux.
Vous pouvez redéfinir la signification des autres signaux si vous êtes prêt à gérer le système d'exploitation émettant ces signaux en réponse à des événements. Vous pouvez par exemple make HUP signifie "configuration de rechargement" - tant que vous êtes certain que le processus n'obtiendra jamais de blocage (perte de terminal), ou que vous êtes prêt à gérer les cas où le système d'exploitation et non un utilisateur envoie le signal HUP.
HUP est l'abréviation de "raccrocher". Ce signal est envoyé à un processus si son terminal de contrôle atteint la fin du fichier. Autrefois, les terminaux de contrôle étaient généralement connectés à des ports série, éventuellement via une liaison modem sur une ligne téléphonique. Si la connexion téléphonique était interrompue, le modem local abaisserait la ligne Carrier Detect, ce qui entraînerait l'envoi par le noyau de la fin du fichier et un signal SIGHUP.
WINCH est l'abréviation de "changement de fenêtre". Il est envoyé à un processus si son terminal de contrôle change de taille. Pour des raisons évidentes, les terminaux qui peuvent changer de taille sont généralement des pseudo-terminaux finalement représentés par un émulateur de terminal fonctionnant dans un environnement de fenêtrage (comme xterm).
Essayez kill -l et trouvez vous-même la réponse:
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP
21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR
31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3
38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8
43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7
58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2
63) SIGRTMAX-1 64) SIGRTMAX
Parce que les noms des signaux sont standardisés (par POSIX). Vous pouvez écrire votre propre exécutable de type kill pour prendre -UPGRADE si vous le souhaitez et faites-le livrer le USR1 signal, mais le standard kill fourni avec UNIX ne le reconnaîtra pas.
Vous pouvez également créer un alias, une fonction ou un script Shell pour effectuer la traduction à votre place, comme avec l'alias bash:
alias upgrade='kill -USR1'
Le signal.h le fichier d'en-tête mappe les noms des signaux à leurs valeurs réelles, qui dépendent de l'implémentation.
En termes de WINCH, je considère cela comme une abomination. Il s'agit du signal délivré aux applications lorsque la taille de leur fenêtre change (en particulier lorsque la fenêtre de leur terminal de contrôle change).
L'utiliser pour arrêter gracieusement les threads de travail n'est pas une bonne idée, sauf si vous pouvez garantir que le processus ne s'exécutera jamais dans un terminal. Je sais que je serais assez vexé si j'exécutais une application et il a décidé d'annuler tout le travail en vol juste parce que j'ai maximisé la fenêtre :-)
Les noms de signaux proviennent de périodes antérieures à Posix.
Je veux parler de SIG ** IOT **. À l'époque où les mainframes DEC PDP étaient utilisés, le ou les processeurs utilisés avaient une instruction IOT spéciale (I/O Trap) qui était souvent utilisée pour doucement planter le système - le forçant généralement à redémarrer (dans les serveurs en temps réel). L'ensemble du noyau ainsi que les pilotes de périphériques et les processus privilégiés (écrits en assembleur) ont utilisé cette méthode. Aujourd'hui encore, certains processeurs disposent encore de cette instruction IOT.
Ainsi, lorsque le noyau subit une exécution d'une instruction IOT dans un domaine non privilégié, il déclenche un SIGIOT pour le processus affecté.
Sur les plates-formes compatibles POSIX, SIGUSR1 et SIGUSR2 sont des signaux envoyés à un processus pour indiquer des conditions définies par l'utilisateur. Les constantes symboliques pour eux sont définies dans le fichier d'en-tête signal.h . Les noms de signaux symboliques sont utilisés car les numéros de signaux peuvent varier d'une plateforme à l'autre.
SIG est un préfixe commun pour les noms de signaux. USR est une abréviation de défini par l'utilisateur.