killall me da "no se encontró ningún proceso" pero

¿Podría alguien explicarme la diferencia entre killy killall? ¿Por qué no killallve lo que psmuestra?

# ps aux |grep db2
root      1123  0.0  0.8 841300 33956 pts/1    Sl   11:48   0:00 db2wdog                                         
db2inst1  1125  0.0  3.5 2879496 143616 pts/1  Sl   11:48   0:02 db2sysc                                        
root      1126  0.0  0.6 579156 27840 pts/1    S    11:48   0:00 db2ckpwd                                        
root      1127  0.0  0.6 579156 27828 pts/1    S    11:48   0:00 db2ckpwd                                        
root      1128  0.0  0.6 579156 27828 pts/1    S    11:48   0:00 db2ckpwd 

# killall db2ckpwd
db2ckpwd: no process found

# kill -9 1126
# kill -9 1127
# kill -9 1128

El sistema es SuSe 11.3 (64 bit); núcleo 2.6.34-12; procps versión 3.2.8; killall de PSmisc 22.7; matar desde GNU coreutils 7.1

¿Está esto en Linux?

En realidad, hay algunas versiones ligeramente diferentes del nombre del comando que son utilizados por ps, killall, etc.

Las dos variantes principales son: 1) el nombre de comando largo, que es lo que obtienes cuando corres ps u; y 2) el nombre corto del comando, que es lo que obtienes cuando corres pssin ningún indicador.

Probablemente la mayor diferencia ocurre si su programa es un script de shell o cualquier cosa que requiera un intérprete, por ejemplo, Python, Java, etc.

Aquí hay un script realmente trivial que demuestra la diferencia. Lo llamé mycat:

#!/bin/sh
cat

Después de ejecutarlo, aquí están los dos tipos diferentes de ps.

Primero, sin u:

$ ps -p 5290
  PID TTY      ... CMD
 5290 pts/6    ... mycat

En segundo lugar, con u:

$ ps u 5290
USER       PID ... COMMAND
mikel     5290 ... /bin/sh /home/mikel/bin/mycat

¿Observa cómo comienza la segunda versión /bin/sh?

Ahora, por lo que puedo decir, en killallrealidad lee /proc/<pid>/staty toma la segunda palabra entre los parens como el nombre del comando, así que eso es realmente lo que necesitas especificar cuando corres killall. Lógicamente, eso debería ser lo mismo que dice psla ubandera, pero sería una buena idea verificarlo.

Cosas para verificar:

1. ¿Qué cat /proc/<pid>/statdice el nombre del comando?
2. ¿Qué ps -e | grep db2dice el nombre del comando?
3. hacer ps -e | grep db2y ps au | grep db2mostrar el mismo nombre de comando?

Notas

Si también está utilizando otros indicadores ps, puede que le resulte más fácil de usar ps -o commpara ver el nombre corto y ps -o cmdel nombre largo.

También puede encontrar pkilluna mejor alternativa. En particular, pkill -fintenta hacer coincidir usando el nombre completo del comando, es decir, el nombre del comando tal como se imprime con ps uo ps -o cmd.

killall intenta hacer coincidir el nombre de un proceso (pero en realidad no es tan bueno en la parte correspondiente).

Y como "ps | grep" y "ps | grep | kill" funcionan mucho mejor, alguien simplificó esto y creó pgrep y pkill. Lea los comandos como "ps grep" y "ps kill", ya que ese comando primero ps luego grep y si lo desea mata.

Tuve un problema similar pero /proc/<pid>/statcontenía la cadena esperada. Al usar strace pude ver que Killall también accedió /proc/<pid>/cmdline.

Continué investigando usando gdb para encontrar que en mi caso falló en una verificación de mi comando al comando completo, incluidos todos los args encontrados /proc/<pid>/cmdline. Parecía que esa ruta del código se activó debido a que el nombre del archivo tenía más de 15 caracteres (que es un valor codificado en la fuente de killall). No investigué completamente si de alguna manera podría hacer que funcionara con killall.

Pero como se menciona en otros comentarios aquí, pkill es una mejor alternativa que no tiene los mismos problemas.

El código fuente de pkillse puede encontrar aquí https://github.com/acg/psmisc para los interesados.

En los sistemas Ubuntu 16, / proc / pid / stat contendrá el nombre del hilo (que un programa puede llamar a través del sistema pthread_setname_np ).