En sistemas POSIX, señales de terminación por lo general tienen el siguiente orden (de acuerdo con muchas páginas de manual y el Spec POSIX):¿Cómo se relaciona SIGINT con las otras señales de terminación?
SIGTERM - cortésmente pedir a un proceso para terminar. Terminará correctamente, limpiando todos los recursos (archivos, sockets, procesos secundarios, etc.), eliminando archivos temporales, etc.
SIGQUIT - solicitud más enérgica. Terminará sin gracia, sigue limpiando los recursos que absolutamente necesitan limpieza, pero tal vez no elimine los archivos temporales, tal vez escriba información de depuración en alguna parte; en algún sistema también se escribirá un volcado del núcleo (independientemente de si la señal es capturada por la aplicación o no).
SIGKILL - petición más enérgica. El proceso ni siquiera se pide que haga nada, pero el sistema limpiará el proceso, ya sea que así sea o no. Lo más probable es que se escriba un volcado del núcleo.
¿Cómo encaja SIGINT en esa imagen? Un proceso CLI usualmente es terminado por SIGINT cuando el usuario golpea CRTL + C, sin embargo, un proceso de fondo también puede ser terminado por SIGINT usando la utilidad KILL. Lo que no puedo ver en las especificaciones o en los archivos de encabezado es si SIGINT es más o menos enérgico que SIGTERM o si hay alguna diferencia entre SIGINT y SIGTERM en absoluto.
ACTUALIZACIÓN:
La mejor descripción de señales de terminación he encontrado hasta ahora es en el GNU LibC Documentation. Explica muy bien que existe una diferencia intencionada entre SIGTERM y SIGQUIT.
que dice acerca de SIGTERM:
Es la forma normal de pedir educadamente un programa para terminar.
Y que dice acerca de SIGQUIT:
[...] y produce un volcado de memoria cuando se termina el proceso, al igual que una señal de error del programa. Puede considerar esto como una condición de error del programa "detectada" por el usuario. [...] Ciertos tipos de limpiezas se omiten mejor al manejar SIGQUIT. Por ejemplo, si el programa crea archivos temporales, debe manejar las otras solicitudes de terminación eliminando los archivos temporales . Pero es mejor para SIGQUIT no eliminarlos, para que el usuario pueda examinarlos en junto con el volcado del núcleo.
Y SIGHUP también se explica lo suficiente. SIGHUP no es realmente una señal de terminación, solo significa que la "conexión" al usuario se ha perdido, por lo que la aplicación no puede esperar que el usuario lea ningún resultado adicional (por ejemplo, la salida stdout/stderr) y no hay información que esperar de la usuario por más tiempo Para la mayoría de las aplicaciones eso significa que es mejor dejarlo. En teoría, una aplicación también podría decidir que entra en modo daemon cuando se recibe un SIGHUP y ahora se ejecuta como un proceso en segundo plano, escribiendo salida en un archivo de registro configurado. Para la mayoría de los daemons que ya se ejecutan en segundo plano, SIGHUP generalmente significa que deben volver a examinar sus archivos de configuración, por lo que lo envía a procesos en segundo plano después de editar los archivos de configuración.
Sin embargo, no hay una explicación útil de SIGINT en esta página, salvo que se envía por CRTL + C. ¿Hay alguna razón por la cual uno manejaría SIGINT de una manera diferente que SIGTERM? Si es así, ¿qué razón sería esto y cómo sería el manejo diferente?
Buena pregunta. Sospecho que parte de la cruzada histórica de Unix estaría involucrada en la respuesta. –
Sé que esta pregunta es antigua, pero en caso de que alguien venga aquí para obtener una lista exhaustiva de señales para su sistema operativo (Linux), se pueden encontrar escribiendo 'sudo fuser -l' en el símbolo del sistema. Para mí esto trae a colación: 'HUP INT SALIR ILL TRAP ABRT IOT BUS FPE KILL USR1 SEGV USR2 PIPE ALRM TERM STKFLT CHLD CONT STOP TSTP TTIN TTOU URG XCPU XFSZ VTALRM PROF WINCH IO PWR SYS UNUSED ' –
También intenta' kill -l' para una lista de señales. – AAAfarmclub