Quel est le lien entre SIGINT et les autres signaux de terminaison?

sur les systèmes POSIX, les signaux de terminaison ont généralement l'ordre suivant (selon de nombreuses pages de manuel et la spécification POSIX):

1. SIGTERM - poliment demander un processus pour terminer. Il doit se terminer avec élégance, en nettoyant toutes les ressources (fichiers, sockets, processus enfants, etc.), la suppression des fichiers temporaires et ainsi de suite.

2. SIGQUIT - plus énergique de la demande. Il doit mettre fin disgracieux, encore nettoyer des ressources qui ont absolument besoin de nettoyage, mais peut-être pas supprimer des fichiers temporaires, peut-être écrire des informations de débogage quelque part; sur certains systèmes aussi un dump core sera écrit (indépendamment du fait que le signal est saisi par l'application ou non).

3. SIGKILL - plus énergique de la demande. On ne demande même pas au processus de faire quoi que ce soit, mais le système nettoiera le processus, qu'il le veuille ou non. Très probablement un dump de noyau est écrit.

comment SIGINT s'intègre-t-il dans cette image? Un processus CLI est habituellement terminé par SIGINT lorsque L'utilisateur tape CRTL+C, mais un processus de fond peut aussi être terminé par SIGINT en utilisant l'utilitaire KILL. Ce que je ne vois pas dans les spécifications ou les fichiers d'en-tête, c'est si SIGINT est plus ou moins fort que SIGTERM ou s'il y a une différence entre SIGINT et SIGTERM.

mise à jour:

Le meilleur la description des signaux de terminaison que j'ai trouvée jusqu'à présent se trouve dans la Documentation GNU LibC . Il explique très bien qu'il y a une différence voulue entre SIGTERM et SIGQUIT.

Il dit à propos de SIGTERM:

c'est la manière normale de demander poliment à un programme d'arrêter.

et il est dit à propos de SIGQUIT:

[...] et produit un noyau dump quand il termine le processus, tout comme un programme de signal d'erreur. Vous pouvez considérer cela comme une erreur de programme d'état "détecté" par l'utilisateur. [...] Certains types de nettoyage sont mieux omis dans la manipulation de SIGQUIT. Par exemple, si le programme crée des fichiers temporaires, il devrait traiter les autres demandes de résiliation en supprimant le temporaire fichier. Mais il est préférable pour SIGQUIT de ne pas les supprimer, de sorte que l'utilisateur peut les examiner dans en conjonction avec le vidage du cœur.

et SIGHUP est également assez bien expliqué. SIGHUP n'est pas vraiment un signal de terminaison, cela signifie simplement que la "connexion" à l'Utilisateur a été perdue, de sorte que l'application ne peut pas s'attendre à ce que l'utilisateur Lise une sortie supplémentaire (par exemple stdout/stderr output) et il n'y a plus d'entrée à attendre de l'utilisateur. Pour la plupart des applications qui signifie qu'ils feraient mieux d'arrêter. En théorie une application pourrait également décider qu'il va en mode démon quand un soupir est reçu et fonctionne maintenant comme un processus de fond, l'écriture la sortie vers un fichier journal configuré. Pour la plupart des démons déjà en arrière-plan, SIGHUP signifie généralement qu'ils vont réexaminer leurs fichiers de configuration, donc vous les envoyez aux processus en arrière-plan après avoir édité les fichiers de configuration.

cependant, il n'y a pas d'explication utile de SIGINT sur cette page, si ce n'est qu'elle est envoyée par CRTL+C. y a-t-il une raison pour laquelle on traiterait SIGINT d'une manière différente de SIGTERM? Si oui, pour quelle raison serait-ce et comment la manipulation être différents?