¿Cómo puedo matar un proceso y asegurarme de que el PID no se haya reutilizado?

Supongamos, por ejemplo, que tiene un script de shell similar a:

longrunningthing &
p=$!
echo Killing longrunningthing on PID $p in 24 hours
sleep 86400
echo Time up!
kill $p

Debería hacer el truco, ¿no? Excepto que el proceso puede haber terminado antes y su PID puede haber sido reciclado, lo que significa que algún trabajo inocente obtiene una bomba en su cola de señal. En la práctica, esto posiblemente importa, pero de todos modos me preocupa. Hackear algo largo para caer muerto por sí mismo, o mantener / eliminar su PID en el FS funcionaría, pero estoy pensando en la situación genérica aquí.

Lo mejor sería usar el timeoutcomando si lo tiene, que está destinado para eso:

timeout 86400 cmd

La implementación actual de GNU (8.23) al menos funciona utilizando alarm()o equivalente mientras espera el proceso secundario. No parece estar protegiendo contra la SIGALRMentrega entre el waitpid()regreso y la timeoutsalida (cancelando efectivamente esa alarma ). Durante esa pequeña ventana, timeoutincluso puede escribir mensajes en stderr (por ejemplo, si el niño arrojó un núcleo), lo que agrandaría aún más esa ventana de carrera (indefinidamente si stderr es una tubería completa, por ejemplo).

Personalmente, puedo vivir con esa limitación (que probablemente se solucionará en una versión futura). timeouttambién tendrá mucho cuidado de informar el estado de salida correcto, manejar otros casos de esquina (como SIGALRM bloqueado / ignorado en el inicio, manejar otras señales ...) mejor de lo que probablemente podría hacer a mano.

Como aproximación, podría escribirlo perlcomo:

perl -MPOSIX -e '
  $p = fork();
  die "fork: $!\n" unless defined($p);
  if ($p) {
    $SIG{ALRM} = sub {
      kill "TERM", $p;
      exit 124;
    };
    alarm(86400);
    wait;
    exit (WIFSIGNALED($?) ? WTERMSIG($?)+128 : WEXITSTATUS($?))
  } else {exec @ARGV}' cmd

Hay un timelimitcomando en http://devel.ringlet.net/sysutils/timelimit/ (precede a GNU timeoutpor unos meses).

 timelimit -t 86400 cmd

Ese usa un alarm()mecanismo similar pero instala un controlador SIGCHLD(ignorando a los niños detenidos) para detectar la muerte del niño. También cancela la alarma antes de ejecutar waitpid()(eso no cancela la entrega de SIGALRMsi estaba pendiente, pero por la forma en que está escrito, no puedo ver que sea un problema) y mata antes de llamar waitpid()(así que no puedo matar un pid reutilizado )

netpipes también tiene un timelimitcomando. Ese precede a todos los demás por décadas, adopta otro enfoque, pero no funciona correctamente para los comandos detenidos y devuelve un 1estado de salida al finalizar el tiempo de espera.

Como respuesta más directa a su pregunta, puede hacer algo como:

if [ "$(ps -o ppid= -p "$p")" -eq "$$" ]; then
  kill "$p"
fi

Es decir, verifique que el proceso todavía sea un hijo nuestro. Nuevamente, hay una pequeña ventana de carrera (entre psrecuperar el estado de ese proceso y killmatarlo) durante el cual el proceso podría morir y su pid será reutilizado por otro proceso.

Con algunas conchas ( zsh, bash, mksh), puede pasar especificaciones de trabajo en lugar de los PID.

cmd &
sleep 86400
kill %
wait "$!" # to retrieve the exit status

Eso solo funciona si genera un solo trabajo en segundo plano (de lo contrario, obtener la especificación de trabajo correcta no siempre es posible de manera confiable).

Si eso es un problema, simplemente inicie una nueva instancia de shell:

bash -c '"$@" & sleep 86400; kill %; wait "$!"' sh cmd

Eso funciona porque el shell elimina el trabajo de la tabla de trabajos cuando el niño muere. Aquí, no debería haber ninguna ventana de carrera ya que para cuando el shell llama kill(), o la señal SIGCHLD no se ha manejado y el pid no se puede reutilizar (ya que no se ha esperado), o se ha manejado y el el trabajo se ha eliminado de la tabla de procesos (e killinformaría un error). bash's killal menos bloquea SIGCHLD antes de acceder a su tabla de trabajo para expandirlo %y desbloquearlo después de kill().

Otra opción para evitar tener ese sleepproceso dando vueltas incluso después de que cmdhaya muerto, con basho ksh93es usar una tubería con en read -tlugar de sleep:

{
  {
    cmd 4>&1 >&3 3>&- &
    printf '%d\n.' "$!"
  } | {
    read p
    read -t 86400 || kill "$p"
  }
} 3>&1

Ese todavía tiene condiciones de carrera, y pierdes el estado de salida del comando. También supone cmdque no cierra su fd 4.

Podrías intentar implementar una solución libre de carrera en perl:

perl -MPOSIX -e '
   $p = fork();
   die "fork: $!\n" unless defined($p);
   if ($p) {
     $SIG{CHLD} = sub {
       $ss = POSIX::SigSet->new(SIGALRM); $oss = POSIX::SigSet->new;
       sigprocmask(SIG_BLOCK, $ss, $oss);
       waitpid($p,WNOHANG);
       exit (WIFSIGNALED($?) ? WTERMSIG($?)+128 : WEXITSTATUS($?))
           unless $? == -1;
       sigprocmask(SIG_UNBLOCK, $oss);
     };
     $SIG{ALRM} = sub {
       kill "TERM", $p;
       exit 124;
     };
     alarm(86400);
     pause while 1;
   } else {exec @ARGV}' cmd args...

(aunque necesitaría ser mejorado para manejar otros tipos de casos de esquina).

Otro método sin raza podría ser el uso de grupos de procesos:

set -m
((sleep 86400; kill 0) & exec cmd)

Sin embargo, tenga en cuenta que el uso de grupos de procesos puede tener efectos secundarios si hay E / S en un dispositivo terminal involucrado. Sin embargo, tiene el beneficio adicional de matar todos los demás procesos adicionales generados por cmd.

En general, no puedes. Todas las respuestas dadas hasta ahora son heurísticas con errores. Solo hay un caso en el que puede usar con seguridad el pid para enviar señales: cuando el proceso de destino es un hijo directo del proceso que enviará la señal, y el padre aún no lo ha esperado. En este caso, incluso si ha salido, el pid está reservado (esto es lo que es un "proceso zombie") hasta que el padre lo espere. No conozco ninguna forma de hacerlo limpiamente con el shell.

Una forma segura alternativa de eliminar procesos es iniciarlos con un conjunto de control tty en un pseudo-terminal para el cual es dueño del lado maestro. Luego puede enviar señales a través del terminal, por ejemplo, escribiendo el carácter para SIGTERMo SIGQUITsobre el pty.

Otra forma más conveniente de crear scripts es utilizar una screensesión con nombre y enviar comandos a la sesión de pantalla para finalizarla. Este proceso se lleva a cabo a través de una tubería o un conector Unix nombrado de acuerdo con la sesión de pantalla, que no se reutilizará automáticamente si elige un nombre único seguro.

1. Al iniciar el proceso, guarde su hora de inicio:

   longrunningthing &
   p=$!
   stime=$(TZ=UTC0 ps -p "$p" -o lstart=)
   
   echo "Killing longrunningthing on PID $p in 24 hours"
   sleep 86400
   echo Time up!
   

2. Antes de intentar matar el proceso, deténgalo (esto no es realmente esencial, pero es una forma de evitar las condiciones de carrera: si detiene el proceso, su pid no se puede reutilizar)

   kill -s STOP "$p"
   

3. Verifique que el proceso con ese PID tenga la misma hora de inicio y, en caso afirmativo, elimínelo; de lo contrario, deje que el proceso continúe:

   cur=$(TZ=UTC0 ps -p "$p" -o lstart=)
   
   if [ "$cur" = "$stime" ]
   then
       # Okay, we can kill that process
       kill "$p"
   else
       # PID was reused. Better unblock the process!
       echo "long running task already completed!"
       kill -s CONT "$p"
   fi
   

Esto funciona porque solo puede haber un proceso con el mismo PID y hora de inicio en un sistema operativo determinado.

Detener el proceso durante la verificación hace que las condiciones de carrera no sean un problema. Obviamente, esto tiene el problema de que algunos procesos aleatorios pueden detenerse durante algunos milisegundos. Dependiendo del tipo de proceso, esto puede o no ser un problema.

Personalmente, simplemente usaría python y psutilque maneja la reutilización de PID automáticamente:

import time

import psutil

# note: it would be better if you were able to avoid using
#       shell=True here.
proc = psutil.Process('longrunningtask', shell=True)
time.sleep(86400)

# PID reuse handled by the library, no need to worry.
proc.terminate()   # or: proc.kill()

En un sistema Linux, puede asegurarse de que un pid no se reutilizará manteniendo vivo su espacio de nombres pid. Esto se puede hacer a través del /proc/$pid/ns/pidarchivo.

• man namespaces -

  El montaje de enlace (consulte mount(2)) uno de los archivos de este directorio en otro lugar del sistema de archivos mantiene vivo el espacio de nombres correspondiente del proceso especificado por pid, incluso si todos los procesos actualmente en el espacio de nombres finalizan.

  Al abrir uno de los archivos en este directorio (o un archivo que está montado en un enlace a uno de estos archivos) se devuelve un identificador de archivo para el espacio de nombres correspondiente del proceso especificado por pid. Mientras este descriptor de archivo permanezca abierto, el espacio de nombres permanecerá vivo, incluso si todos los procesos en el espacio de nombres finalizan. El descriptor de archivo se puede pasar a setns(2).

• man pid_namespaces -

  El primer proceso creado en un nuevo espacio de nombres (es decir, el proceso creado usando clone(2) el indicador CLONE_NEWPID , o el primer hijo creado por un proceso después de una llamada para unshare(2)usar el indicador CLONE_NEWPID ) tiene el PID 1 , y es el initproceso para el espacio de nombres ( ver init(1)) . Un proceso hijo que queda huérfano dentro del espacio de nombres será reparentado a este proceso en lugar de init(1) (a menos que uno de los antepasados ​​del niño en el mismo espacio de nombres PID emplee el comando prctl(2) PR_SET_CHILD_SUBREAPER para marcarse como el segador de procesos descendientes huérfanos) .

  Si el initproceso de un espacio de nombres PID termina, el núcleo termina todos los procesos en el espacio de nombres a través de una señal SIGKILL . Este comportamiento refleja el hecho de que el initproceso es esencial para el correcto funcionamiento de un espacio de nombres PID .

unshare -fp sh -c 'n=
    echo "PID = $$"
    until   [ "$((n+=1))" -gt 5 ]
    do      while   sleep 1
            do      date
            done    >>log 2>/dev/null   &
    done;   sleep 5' >log
cat log; sleep 2
echo 2 secs later...
tail -n1 log

Si no ha organizado un espacio de nombres de usuario, aún puede ejecutar comandos arbitrarios de forma segura eliminando inmediatamente los privilegios. El runusercomando es otro binario (no setuid) provisto por el util-linuxpaquete e incorporarlo podría verse así:

sudo unshare -fp runuser -u "$USER" -- sh -c '...'

...y así.

En el ejemplo anterior dos interruptores se pasan a unshare(1)la --forkbandera que hace que la invoca sh -cproceso creó el primer hijo y asegura su initestado y la --pidbandera que indica a unshare(1)crear un espacio de nombres PID.

El sh -cproceso genera cinco shells secundarios en segundo plano, cada uno un whileciclo infinito que continuará agregando la salida dateal final de logmientras el tiempo sea sleep 1verdadero. Después de generar estos procesos, se shrequieren sleep5 segundos adicionales y luego finaliza.

Quizás valga la pena señalar que si -fno se usara la bandera, ninguno de los whilebucles de fondo terminaría, pero con él ...

SALIDA:

PID = 1
Mon Jan 26 19:17:45 PST 2015
Mon Jan 26 19:17:45 PST 2015
Mon Jan 26 19:17:45 PST 2015
Mon Jan 26 19:17:45 PST 2015
Mon Jan 26 19:17:45 PST 2015
Mon Jan 26 19:17:46 PST 2015
Mon Jan 26 19:17:46 PST 2015
Mon Jan 26 19:17:46 PST 2015
Mon Jan 26 19:17:46 PST 2015
Mon Jan 26 19:17:46 PST 2015
Mon Jan 26 19:17:47 PST 2015
Mon Jan 26 19:17:47 PST 2015
Mon Jan 26 19:17:47 PST 2015
Mon Jan 26 19:17:47 PST 2015
Mon Jan 26 19:17:47 PST 2015
Mon Jan 26 19:17:48 PST 2015
Mon Jan 26 19:17:48 PST 2015
Mon Jan 26 19:17:48 PST 2015
Mon Jan 26 19:17:48 PST 2015
Mon Jan 26 19:17:48 PST 2015
2 secs later...
Mon Jan 26 19:17:48 PST 2015

Considera mejorar tu longrunningthingcomportamiento un poco, un poco más como un demonio. Por ejemplo, puede hacer que cree un archivo pid que permita al menos un control limitado del proceso. Hay varias formas de hacer esto sin modificar el binario original, todas involucrando un contenedor. Por ejemplo:

1. un script de envoltura simple que iniciará el trabajo requerido en segundo plano (con redirección de salida opcional), escriba el PID de este proceso en un archivo, luego espere a que el proceso termine (usando wait) y elimine el archivo. Si durante la espera el proceso se mata, por ejemplo, por algo como

   kill $(cat pidfile)
   

   el contenedor solo se asegurará de que se elimine el archivo pid.

2. un contenedor de monitor, que colocará su propio PID en algún lugar y capturará (y responderá) las señales que se le envíen. Ejemplo simple:

    #!/bin/bash
    p=0
    trap killit USR1

    killit () {
        printf "USR1 caught, killing %s\n" "$p"
        kill -9 $p
    }

    printf "monitor $$ is waiting\n"
    therealstuff &
    p=%1
    wait $p
    printf "monitor exiting\n"

Ahora, como señalaron @R .. y @ StéphaneChazelas, estos enfoques a menudo tienen una condición de carrera en algún lugar o imponen una restricción en la cantidad de procesos que puede generar. Además, no maneja los casos, donde la longrunningthingbifurcación puede separarse y los niños se separan (lo que probablemente no sea el problema en la pregunta original).

Con los núcleos de Linux recientes (leídos hace un par de años), esto se puede tratar muy bien mediante el uso de cgroups , a saber, el congelador , que, supongo, es lo que usan algunos sistemas modernos de inicio de Linux.

Si está ejecutando en Linux (y algunos otros * nixes), puede verificar si el proceso que pretende matar todavía se usa y si la línea de comando coincide con su largo proceso. Algo como :

echo Time up!
grep -q longrunningthing /proc/$p/cmdline 2>/dev/null
if [ $? -eq 0 ]
then
  kill $p
fi

Una alternativa puede ser verificar durante cuánto tiempo se está ejecutando el proceso que pretende matar, con algo así ps -p $p -o etime=. Puede hacerlo usted mismo extrayendo esta información /proc/$p/stat, pero esto sería complicado (el tiempo se mide en segundos y también deberá usar el tiempo de actividad del sistema /proc/stat).

De todos modos, generalmente no puede asegurarse de que el proceso no se reemplace después de su verificación y antes de matarlo.

Esta es realmente una muy buena pregunta.

La forma de determinar la unicidad del proceso es mirar (a) dónde está en la memoria; y (b) lo que contiene ese recuerdo. Para ser específicos, queremos saber en qué lugar de la memoria está el texto del programa para la invocación inicial, porque sabemos que el área de texto de cada hilo ocupará una ubicación diferente en la memoria. Si el proceso muere y se inicia otro con el mismo pid, el texto del programa para el nuevo proceso no ocupará el mismo lugar en la memoria y no contendrá la misma información.

Entonces, inmediatamente después de iniciar su proceso, haga md5sum /proc/[pid]/mapsy guarde el resultado. Más tarde, cuando desee matar el proceso, haga otro md5sum y compárelo. Si coincide, entonces mata al pid. Si no, no lo hagas.

Para ver esto por ti mismo, lanza dos proyectiles de bash idénticos. Examínelos /proc/[pid]/mapsy encontrará que son diferentes. ¿Por qué? Porque aunque es el mismo programa, ocupan diferentes ubicaciones en la memoria y las direcciones de su pila son diferentes. Entonces, si su proceso muere y su PID se reutiliza, incluso si el mismo comando se relanza con los mismos argumentos , el archivo "mapas" será diferente y sabrá que no está tratando con el proceso original.

Ver: página de manual de proc para más detalles.

Tenga en cuenta que el archivo /proc/[pid]/statya contiene toda la información que otros carteles han mencionado en sus respuestas: edad del proceso, padre pid, etc. Este archivo contiene información estática e información dinámica, por lo que si prefiere utilizar este archivo como base de comparación, luego, al iniciar su longrunningthing, debe extraer los siguientes campos estáticos del statarchivo y guardarlos para compararlos más tarde:

pid, nombre de archivo, pid de padre, id de grupo de proceso, terminal de control, proceso de tiempo iniciado después del inicio del sistema, tamaño del conjunto residente, la dirección del inicio de la pila,

tomados en conjunto, lo anterior identifica de manera única el proceso, por lo que esto representa otro camino a seguir. En realidad, podría salirse con la suya con solo "pid" y "proceso de tiempo iniciado después del arranque del sistema" con un alto grado de confianza. Simplemente extraiga estos campos del statarchivo y guárdelo en algún lugar al iniciar su proceso. Más tarde, antes de matarlo, extráigalo nuevamente y compárelo. Si coinciden, entonces está seguro de que está viendo el proceso original.

Otra forma sería verificar la edad del proceso antes de matarlo. De esa manera, puede asegurarse de no matar un proceso que no se genera en menos de 24 horas. Puede agregar una ifcondición basada en eso antes de matar el proceso.

if [[ $(ps -p $p -o etime=) =~ 1-. ]] ; then
    kill $p
fi

Esta ifcondición verificará si la ID del proceso $pes inferior a 24 horas (86400 segundos).

PD: - El comando ps -p $p -o etime=tendrá el formato<no.of days>-HH:MM:SS

Lo que hago es, después de haber matado el proceso, hacerlo de nuevo. Cada vez que hago eso, la respuesta vuelve, "no hay tal proceso"

allenb   12084  5473  0 08:12 pts/4    00:00:00 man man
allenb@allenb-P7812 ~ $ kill -9 12084
allenb@allenb-P7812 ~ $ kill -9 12084
bash: kill: (12084) - No such process
allenb@allenb-P7812 ~ $ 

No podría ser más simple y he estado haciendo esto durante años sin ningún problema.