Estoy trabajando en un código de servidor que usa fork()
y exec para crear procesos secundarios. El PID del niño se registra cuando fork()
tiene éxito y se limpia cuando se ha detectado la señal CHILD
.¿La señal KILL sale de un proceso de inmediato?
Si el servidor necesita detenerse, todos los programas se eliminan, eventualmente con una señal KILL. Ahora, esto funciona mediante iteración a través de todos los PID registrados y esperando que el manejador de señal CHILD elimine los PID. Esto fallará si el programa hijo no salió correctamente. Por lo tanto, quiero usar kill
en combinación con waitpid
para asegurarme de que la lista PID esté limpia y registrar y hacer otras cosas de lo contrario.
Considérese el siguiente ejemplo de código:
kill(pid, SIGKILL);
waitpid(pid, NULL, WNOHANG);
Extracto de waitpid(2)
:
waitpid(): en caso de éxito, devuelve el identificador de proceso del niño cuyo estado ha cambiado; si se especificó WNOHANG y existen uno o más hijos (s) especificados por pid, pero aún no han cambiado el estado, se devuelve 0. En caso de error, se devuelve -1.
¿El proceso dado por pid
siempre se ha ido antes de que la próxima función entre? ¿waitpid
siempre devolverá -1
en el caso anterior?
Una señal KILL es bastante brutal, ¿por qué no INT o HUP? Y también, ¿cuál es el código de retorno de 'kill' syscall? – fge
"esperando que el manejador de señal CHILD ..." - No hay ningún manejador de señal para SIGKILL, ¿sabes? Todas las señales, excepto SIGSTOP y SIGKILL, harán lo establecido por 'sigaction' (por ejemplo, invocar un controlador), o por defecto. SIGSTOP simplemente se detiene, y SIGKILL simplemente mata el proceso. Siempre. No hay manejo o condicional. (La excepción es que el comando 'kill' falla porque no tiene suficientes derechos.) – Damon
@Damon:' SIGKILL' no puede ser ignorado por el proceso de destino, eso es correcto. Pero esa no es la pregunta/problema.La llamada al sistema 'kill (2)' en el proceso fuente puede regresar antes de que la señal sea evaluada (por el kernel) en el contexto del proceso de destino. 'kill (2)' es básicamente una comunicación asincrónica muy simple y debe tratarse como tal con todas las implicaciones. –