web-dev-qa-db-fra.com

Comment signaler une application sans la tuer sous Linux?

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é?

32
Eric

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

33
Paulo Scardine

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).

3
Milan