No estoy seguro si esas son las únicas razones, pero aquí está mi ejercicio:
Dependiendo de la forma en que escriba un shellscript para eliminar el proceso deseado, podría terminar eliminando el PID de eliminación antes de que elimine su objetivo, tomemos mydaemon por ejemplo:
kill -9 `ps ax | grep mydaemon | awk '{ print $1 }'`
A) SIGPIPE-ing killEn un PID de Linux de 32 bits suele ser un número entero de 15 bits, los desbordamientos ocurren a menudo, hay una gran posibilidad de que los PID grep o awk aparezcan antes que el de mydaemon . En PID de 64 bits, los números suelen ser de 22 bits, es más de 100 veces menos probable que suceda, pero sigue siendo bastante factible.
Al matar cualquiera de sus tuberías, recibirá un SIGPIPE y, por lo general, esto también significa la muerte, por lo tanto, matar sería asesinado antes de matar a mydaemon haciendo que el intento de matar falle.
B) Matar otros PID También, digamos que tenía vi /etc/mydaemon/mydaemon.conf ejecutándose por completo, ese PID también podría eliminarse, sin mencionar los procesos de otros usuarios, ya que es muy probable que esté emitiendo dicho comando como root.
C) Es un bloqueo simple similar a Unix -> No se requiere código/demonio adicional. PidFiles es una forma bastante simple de crear bloqueos manejables por el usuario para evitar que genere un demonio dos veces sin darse cuenta.
Los archivos pid contienen la identificación del proceso (un número) de un programa dado. Por ejemplo, Apache HTTPD puede escribir su número de proceso principal en un archivo pid, que es un archivo de texto normal, nada más que eso, y luego usar la información que contiene para detenerse. También puede usar esa información para terminar el proceso usted mismo, usando cat filename.pid | xargs kill