J'ai une application de surveillance. Il regarde mon application principale qui peut planter pour une raison ou une autre (je sais que c'est mauvais, mais ce n'est pas le but).
J'ai programmé ce chien de garde pour accepter les signaux SIGUSR1 afin d'arrêter de surveiller la présence de mon application. Je le signale avec
kill -SIGUSR1 `pidof myapp`
Cela fonctionne vraiment bien. Mon problème survient lorsque j'essaie de signaler une ancienne version du chien de garde qui n'a pas cette fonctionnalité intégrée. Dans ce cas, le signal d'arrêt tue le chien de garde (termine le processus), ce qui entraîne d'autres complications (redémarrage de l'appareil) .
Existe-t-il un moyen de signaler mon chien de garde avec SIGUSR1 afin qu'il ne se termine pas si ce signal particulier n'est pas géré?
De la documentation GN sur la gestion du signal:
Les signaux SIGUSR1 et SIGUSR2 sont mis de côté pour que vous puissiez les utiliser comme vous le souhaitez. Ils sont utiles pour une communication interprocessus simple, si vous écrivez un gestionnaire de signal pour eux dans le programme qui reçoit le signal. Il y a un exemple montrant l'utilisation de SIGUSR1 et SIGUSR2 dans la section Signalisation d'un autre processus. L'action par défaut consiste à terminer le processus .
L'action par défaut pour SIGINFO est de ne rien faire, donc cela peut être plus approprié:
SIGINFO: Demande d'informations. Dans 4.4 BSD et le système GNU, ce signal est envoyé à tous les processus du groupe de processus de premier plan du terminal de contrôle lorsque l'utilisateur tape le caractère STATUS en mode canonique; voir la section Caractères qui provoquent Signaux. Si le processus est le leader du groupe de processus, l'action par défaut consiste à imprimer des informations d'état sur le système et ce que fait le processus. Sinon, la valeur par défaut est de ne rien faire .
SOUPIR est émis lorsque le terminal de contrôle est fermé, mais comme la plupart des démons ne sont pas attachés à un terminal, il n'est pas rare de l'utiliser comme "rechargement":
Les programmes démons utilisent parfois SIGHUP comme signal pour redémarrer eux-mêmes, la raison la plus courante étant de relire un fichier de configuration qui a été modifié.
BTW, votre chien de garde pourrait lire un fichier de configuration de temps en temps afin de savoir s'il devrait relancer le processus.
Mon préféré pour un chien de garde est superviseur .
$ supervisorctl start someapp
someapp: started
$ supervisorctl status someapp
someapp RUNNING pid 16583, uptime 19:16:26
$ supervisorctl stop someapp
someapp: stopped
Voir si kill -l
renvoie la liste des signaux sur votre plate-forme et essayez certains d'entre eux, mais SIGUSR1 semble être un mauvais choix.
$ kill -l
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
[MISE À JOUR]
Carpetsmoker commente les différences de comportement entre Linux et BSD:
SIGINFO semble fonctionner différemment sur GNU libc & BSD; sur BSD, cela fonctionne comme vous le décrivez, mais sous Linux, il n'existe pas ou est le même que SIGPWR ... Le GNU semble incorrect à cet égard (votre sortie kill -l n'affiche pas non plus SIGINFO) ... Je ne sais pas pourquoi GNU doesn ne le supporte pas, car je le trouve très utile ... - Carpetsmoker
L'action par défaut lors de la réception d'un SIGUSR1 est de se terminer si le gestionnaire n'est pas présent. Cela signifie que vous ne pouvez plus faire ce que vous voulez avec ce signal.
À moins de mettre à jour le chien de garde, vous ne pouvez rien faire (et je suppose que vous ne pouvez pas différencier les versions du chien de garde du programme avant d'envoyer le signal).