¿Cuál es la diferencia entre 'killall' y 'pkill'?


92

Después de usar simplemente kill <some_pid>en sistemas Unix desde hace muchos años, he aprendido pkillde un joven Linux-comprensión compañero de trabajo colega 1 .

Pronto acepté la forma de Linux, pgrep-ing y pkill-ing a través de muchos días y noches, a través de ralentizaciones y condiciones de carrera. Todo esto estuvo muy bien.

Pero ahora no veo nada más que killall. Parece que los procedimientos solo mencionan killall, y no estoy seguro de si esto es algún tipo de desarrollo paralelo, o si killalles un sucesor pkillu otra cosa.

Parece funcionar como un objetivo más específico pkill, pero estoy seguro de que me falta algo.

¿Puede una persona Ubuntu / Debian-savvy 2 explicar cuándo (o por qué) killalldebe usarse, especialmente si debe usarse con preferencia pkill(cuando a pkillmenudo parece más fácil, porque puedo ser más descuidado con la coincidencia de nombres, al menos por defecto).

Cuando hablo killall, no estoy pensando en el comando que en algunos sistemas Unix (Solaris, AIX,?) Mataría todos los procesos de los usuarios. Aquí hay una descripción de esa versión, de una página de manual para AIX de IBM :

El comando killall cancela todos los procesos que inició, excepto los que producen el proceso killall. Este comando proporciona un medio conveniente para cancelar todos los procesos creados por el shell que usted controla. Cuando lo inicia un usuario root, el comando killall cancela todos los procesos cancelables, excepto aquellos procesos que lo iniciaron. Si se especifican varias señales, solo la última es efectiva.

1 'colega' es una actualización gratuita de 'compañero de trabajo', también podría serlo.
2 Originalmente pensé que esto era una cosa de Linux o Debian, pero algunas fuentes dicen que Linux killallse deriva de Unix con sabor a BSD.

Respuestas:


68

Creo que ve killall en instrucciones porque, de forma predeterminada, requiere el nombre preciso del proceso, mientras que pkill hace una coincidencia de patrones básica. Por lo tanto, killall es más seguro para los usuarios copiar y pegar a ciegas.

Pkill y Killall tienen dos opciones distintivas. Killall tiene una bandera para que coincida con la edad del proceso, pkill tiene una bandera para matar solo los procesos en un tty determinado. Etcetera ad nauseum. Tampoco es mejor , solo tienen diferentes especialidades.

Veo en sus páginas de manual que killall proviene del paquete psmisc , que tiene varias utilidades de administración de procesos, pero notablemente no contiene ps. Es el paquete procps que tiene ps, top, kill y pkill (entre otros). Apostaría a que procps originalmente no tenía pkill, por lo que psmisc se rascó una picazón y se le ocurrió killall.

La página de manual pkill / pgrep dice que se introdujeron en Solaris 7. Como mencionas, jgbelacqua , killall de Solaris no era la utilidad que psmisc proporciona, por lo tanto, Solaris probablemente solo tenía el paquete procps. Alguien quería una herramienta de proceso de coincidencia de patrones, por lo tanto pkill y pgrep. Si fue desarrollado por el desarrollador de procps o agregado después, no lo sé. De todos modos, lo logró y se convirtió en parte de * nixes en todas partes.

Más fuentes:


1
Hmm: había un killallsistema Solaris (¿antiguo?), Pero se comportó de manera diferente. Lo mató todo.
belacqua

66
@manish - er, hubo un killall diferente en los sistemas SysV.
belacqua

1
@djeikyb La idea de que killall sea más seguro suena bien, o al menos eso podría explicar gran parte de su popularidad.
belacqua

55
@Manish: pkill (no kill) no necesita el número pid ni el nombre del proceso. Hace coincidir el patrón con el nombre del proceso.
Javier Rivera

3
killall is safer for users to blindly copy and paste, excepto si estás en una máquina donde Killall realmente mata a todos. Es lamentable que las dos utilidades diferentes tengan el mismo nombre.
Mentira Ryan

7

Tenga cuidado con "killall". En algunos sistemas (se me olvida cuál), killall mata todos los procesos. Ignorará silenciosamente los argumentos y detendrá su sistema por completo.


55
Esto no es verdad. killall sin ningún argumento no hará nada, y killall no ignorará los argumentos. kill -9 -1podría matar su sistema, y killall -9 -1podría también. Pero no solokillall [program]
Thomas Ward

66
Es cierto en los sistemas SysV, como se menciona ahora en la pregunta original.
alanc

3

si activa / etc / bash_completion, después killall <part_of_process_name>y presiona la pestaña - auto completa el nombre del proceso de la lista de procesos en ejecución


2
El mismo autocompletado se realizará con pgrep / pkill. Algo que comúnmente hago es pkill plug<tab>eliminar el plugin flash para Firefox cuando sé que no tengo nada que quiera usar por un tiempo, pero aún quiero usar Firefox activamente. Esta es una función del shell, no una diferencia entre killall y pgrep / pkill.
Arcege

1
No dije que fuera una diferencia, solo una buena característica para evitar la búsqueda de PID, nombres de procesos, etc.
jet

2

Si observa las opciones en ambos programas, verá que ambos hacen casi lo mismo, pero de diferentes maneras.

pkill realizará la coincidencia en varios atributos de un proceso (CMD, PID, PPID, UID ...) y enviará la señal dada a cada proceso que coincida. (Para CMD, se usa una expresión regular, para otros es una cadena). pkill no es interactivo, pero es mejor para programas por lotes.

killall realizará una coincidencia en el nombre del proceso (comm) o usuario (usuario), no en la cadena de comando completa. El argumento se usa como una cadena simple y debe coincidir con todo el valor 'comm' (también hay una opción --regexp para cambiar esto). killall tiene opciones --interactive y --younger- than, que pkill no tiene.

También hay un killall5 de días SysV y fue portado a otras variantes de UNIX (supuestamente bajo el paquete de Ubuntu 'sysutils'). Esto se comporta de manera diferente a la antigua usanza. Esto a menudo se usaba internamente en los scripts de inicio para apagar o cambiar al modo de usuario único.


2
No, pkillni killalldebe usarse en scripts, solo de forma interactiva y con precaución.
geirha
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.