¿Por qué no puedo eliminar un proceso SIGSTOP con un SIGTERM y dónde se almacena la señal pendiente?

Estoy usando Debian stretch (systemd). Estaba ejecutando el demonio rsyslog en primer plano usando /usr/sbin/rsyslogd -n e hice un Ctrl+ Zpara detenerlo. El estado del proceso cambió a Tl(detenido, enhebrado). Emití múltiples comandos para el proceso, y el estado del proceso era el mismo: . Una vez que hice un , murió. Tengo 3 preguntaskill -15 <pid>Tlfg

• ¿Por qué el SIGSTOPproceso -ed no respondía SIGTERM? ¿Por qué el núcleo lo mantiene en el mismo estado?
• ¿Por qué lo mataron en el momento en que recibió la SIGCONTseñal?
• Si fue por la SIGTERMseñal anterior , ¿dónde se mantuvo hasta que se reanudó el proceso?

SIGSTOPy SIGKILLson dos señales que no pueden ser captadas y manejadas por un proceso. SIGTSTPes como, SIGSTOPexcepto que puede ser atrapado y manejado.

Las señales SIGSTOPy SIGTSTPdetienen un proceso en su camino, listo para SIGCONT. Cuando envía ese proceso a SIGTERM, el proceso no se está ejecutando y, por lo tanto, no puede ejecutar el código para salir.

(También hay SIGTTINy SIGTTOU, que son señales generadas por la capa TTY cuando un trabajo en segundo plano intenta leer o escribir en el terminal. Se pueden capturar pero de lo contrario se detendrá (suspenderá) el proceso, al igual que SIGTSTP. Pero ahora voy ignorar esos dos por el resto de esta respuesta.)

Su CtrlZenvía el proceso a SIGTSTP, que parece no ser manejado especialmente de ninguna manera rsyslogd, por lo que simplemente suspende el proceso pendiente SIGCONTo SIGKILL.

La solución aquí también es enviar SIGCONTdespués de usted SIGTERMpara que el proceso pueda recibir y manejar la señal.

Ejemplo:

sleep 999 &

# Assume we got PID 456 for this process
kill -TSTP 456    # Suspend the process (nicely)
kill -TERM 456    # Terminate the process (nicely). Nothing happens
kill -CONT 456    # Continue the process so it can exit cleanly

La documentación para la Biblioteca GNU C explica esto bastante bien, creo (mi resaltado):

Mientras se detiene un proceso, no se pueden enviar más señales hasta que continúe , excepto las SIGKILLseñales y (obviamente) las SIGCONTseñales. Las señales se marcan como pendientes, pero no se entregan hasta que se continúa el proceso. La SIGKILLseñal siempre provoca la finalización del proceso y no se puede bloquear, manejar o ignorar. Puede ignorar SIGCONT, pero siempre hace que el proceso continúe de todos modos si se detiene. Al enviar una SIGCONTseñal a un proceso, se descartan las señales de parada pendientes para ese proceso. Del mismo modo, cualquier SIGCONTseñal pendiente para un proceso se descarta cuando recibe una señal de parada.

SIGTERMes como cualquier otra señal que puede ser captada por un proceso. Recibir la señal solo hará que el proceso salte a una rutina especial de manejo de señales. Por SIGTERMla acción por defecto será la de terminar el proceso, pero, por ejemplo, un editor puede gusta coger la señal para que pueda guardar un borrador de los archivos abiertos antes de morir. Si el proceso se detiene, no puede ejecutar el controlador de señal, pero la señal permanecerá pendiente hasta que el proceso continúe. Tenga en cuenta que la cantidad de señales enviadas generalmente no se guardará.

En teoría, el sistema podría saber si el proceso tiene instalado un controlador de señal SIGTERMy finalizarlo inmediatamente si no. Pero (según el comentario de Gilles) POSIX exige que la señal se suspenda hasta que el proceso continúe a través deSIGCONT .