Quels signaux “fatals” un programme de niveau utilisateur doit-il prendre?

Tout d’abord, je sais qu’il y avait une question similaire dans le passé .

Mais cette question n’a pas été répondu correctement. Au lieu de cela, il a détourné dans la suggestion quoi faire pour attraper les signaux.

Donc, juste pour clarifier: j’ai fait tout ce qui doit être fait pour gérer les signaux. J’ai une application qui forge un démon qui surveille le processus principal via le canal. Si un processus principal se bloque (par exemple, une erreur de segmentation), il dispose d’un gestionnaire de signal qui écrit toutes les informations requirejses dans le canal et les abandonne.

Le but est d’avoir autant d’informations que possible lorsque quelque chose de mauvais arrive à l’application , sans avoir à manipuler une opération “normale”, telle que SIGHUP, SIGUSR1, etc.

Donc, ma question est la suivante: quels signaux dois-je prendre? Je veux dire que les signaux sans que je les attrape provoquent l’abandon de l’application.

Jusqu’à présent, j’ai trouvé la liste suivante:

SIGINT (^ C, initié par l’utilisateur, mais toujours bon à savoir)
SIGTERM ( kill du shell ou, AFAIK, peut être le résultat de OutOfMemory)
SIGSEGV
SIGILL
SIGFPE
SIGBUS
SIGQUIT

Est-ce que quelqu’un sait si quelque chose me manque? kill -l a beaucoup … 🙂

Je regarde ma copie de la programmation avancée de l’environnement Unix (Stevens). Selon le tableau de la section sur les signaux, les signaux POSIX suivants termineront le processus par défaut si vous ne les attrapez pas. Il ne serait pas déraisonnable de surveiller tous ceux que vous n’utilisez pas:

SIGABRT
SIGALRM
SIGFPE
SIGHUP
SIGILL
SIGINT
SIGKILL
SIGPIPE
SIGQUIT
SIGSEGV
SIGTERM
SIGUSR1
SIGUSR2

Vous pouvez tout voir sauf SIGKILL, mais espérons que SIGKILL ne viendra pas très souvent pour vous.

Notez que votre page de manuel ( man 7 signal ) devrait vous donner la liste appropriée pour votre système – il s’agit de la liste POSIX, et peut varier en fonction de votre architecture.

Vous ne devriez pas attraper le signal et écrire le code dans un tube. Ceci est à la fois inutile et non sécurisé.

Permettez-moi de citer une réponse à la question à laquelle vous avez lié, pour indiquer pourquoi ce n’est pas sûr: “Qu’est-ce qui vous fait penser qu’un SEGV n’a pas déjà corrompu votre mémoire de programme”

Maintenant, vous vous demandez peut-être comment faire mieux, et pourquoi j’ai dit que c’était “inutile”.

Le code retour de l’ waitpid waitpid peut être vérifié en utilisant WIFSIGNALED() pour déterminer si le processus s’est terminé normalement ou via un signal, et WTERMSIG() renverra le numéro du signal.

Ceci est sûr et ne nécessite pas de gestionnaire ou de canal. De plus, vous n’avez pas à vous soucier de quoi attraper, car il signalera chaque signal qui met fin à votre processus.

Cela dépend: quel que soit le signal que vous aimez, si cela est utile pour informer l’utilisateur que quelque chose de mal est arrivé. Cependant, SIGKILL et SIGSTOP ne peuvent pas être capturés.