Qual é a diferença entre 'killall' e 'pkill'?


92

Depois de usar simplesmente kill <some_pid>em sistemas Unix por muitos anos, eu aprendi pkilla partir de um mais jovem Linux-savvy colega de trabalho colega 1 .

Eu logo aceitou o Linux-way, pgreping e pkilling através de muitos dias e noites, por meio de slow-downs e condições de corrida. Tudo foi muito bem.

Mas agora não vejo mais nada killall. As instruções parecem mencionar apenas killall, e não tenho certeza se isso é algum tipo de desenvolvimento paralelo, ou se killallé um sucessor pkillou algo mais.

Parece funcionar como um alvo pkill, mas tenho certeza de que estou perdendo alguma coisa.

Uma pessoa que conhece o Ubuntu / Debian 2 pode explicar quando (ou por que) killalldeve ser usada, especialmente se deve ser preferida pkill(quando pkillparece mais fácil, porque eu posso ser mais desleixado com a correspondência de nomes, pelo menos por padrão).

Ao falar sobre killall, não estou pensando no comando que em alguns sistemas Unix (Solaris, AIX,?) Mataria todos os processos do usuário. Aqui está uma descrição dessa versão, em uma página de manual do AIX da IBM :

O comando killall cancela todos os processos que você iniciou, exceto aqueles que produzem o processo killall. Este comando fornece um meio conveniente de cancelar todos os processos criados pelo shell que você controla. Quando iniciado por um usuário root, o comando killall cancela todos os processos canceláveis, exceto os processos que o iniciaram. Se vários sinais forem especificados, apenas o último será efetivo.

1 'colega' é atualização gratuita de 'colega de trabalho', assim também pode.
2 Originalmente, eu pensei que isso era algo do Linux ou Debian, mas algumas fontes estão dizendo que o Linux killallé derivado do Unix com sabor de BSD.

Respostas:


68

Eu acho que você vê killall nos procedimentos, porque, por padrão, requer o nome preciso do processo, enquanto o pkill faz a correspondência básica de padrões. Assim, o killall é mais seguro para os usuários copiarem e colarem cegamente.

Pkill e killall têm opções distintas. Killall tem uma bandeira para corresponder à idade do processo, pkill tem uma bandeira para matar apenas processos em um determinado tty. Etcetera ad nauseum. Nem é melhor , eles apenas têm especialidades diferentes.

Vejo em suas páginas de manual que killall vem do pacote psmisc , que possui vários utilitários de gerenciamento de processos, mas notavelmente não contém ps. É o pacote procps que possui ps, top, kill e pkill (entre outros). Eu aposto que procps não tinha pkill originalmente, então psmisc coçou uma coceira e veio com killall.

A página do manual pkill / pgrep diz que eles foram introduzidos no Solaris 7. Como você menciona, jgbelacqua , o killall do Solaris não era o utilitário que o psmisc fornece, portanto o Solaris provavelmente só tinha o pacote procps. Alguém queria uma ferramenta de processo de correspondência de padrões, como pkill e pgrep. Se foi desenvolvido pelo procps dev ou adicionado posteriormente, não sei. Independentemente disso, ele entrou e se tornou parte de * nixes em todos os lugares.

Mais fontes:


1
Hmm - havia um killallsistema Solaris ligado (antigo?), Mas se comportou de maneira diferente. Isso matou tudo.
22411 belacqua

6
@ manish - er, havia um killall diferente nos sistemas SysV.
22411 belacqua

1
@djeikyb O pensamento de que killall é mais seguro parece certo, ou pelo menos isso poderia explicar grande parte de sua popularidade.
22411 belacqua

5
@ Manish: pkill (sem matar) não precisa do número pid, nem do nome do processo. Ele corresponde ao padrão do nome do processo.
Javier Rivera

3
killall is safer for users to blindly copy and paste, exceto se você estiver em uma máquina em que killall realmente mate tudo. É uma pena que os dois utilitários diferentes tenham o mesmo nome.
Lie Ryan

7

Por favor, tenha cuidado com "killall". Em alguns sistemas (esqueço quais), o killall mata todos os processos. Ele ignorará silenciosamente os argumentos e interromperá completamente o seu sistema.


5
Isso não é verdade. killall sem argumentos não fará nada e killall não ignorará os argumentos. kill -9 -1pode matar seu sistema e também killall -9 -1pode. Mas não apenaskillall [program]
Thomas Ward

6
É verdade nos sistemas SysV, como agora mencionado na pergunta original.
Alanc

3

se você ativar / etc / bash_completion, after killall <part_of_process_name>e hit tab - conclui automaticamente o nome do processo na lista de processos em execução


2
O mesmo preenchimento automático será feito com pgrep / pkill. Algo que costumo fazer é pkill plug<tab>matar o plug-in flash do firefox quando sei que não tenho nada que queira usar por um tempo, mas ainda quero ativamente usá-lo. Isso é uma função do shell, não uma diferença entre killall e pgrep / pkill.
Arcege 22/02

1
Eu não disse que é a diferença - apenas um recurso bom para evitar à procura de PIDs, nomes de processo e etc.
jet

2

Se você observar as opções nos dois programas, verá que os dois fazem a mesma coisa, mas de maneiras diferentes.

O pkill fará a correspondência em vários atributos de um processo (CMD, PID, PPID, UID ...) e enviará o sinal fornecido para cada processo que corresponder. (Para CMD, uma expressão regular é usada, para outros é uma string). O pkill não é interativo, mas é melhor para programas em lote.

O killall executará a correspondência no nome do processo (comunicação) ou usuário (usuário), não em toda a cadeia de comando. O argumento é usado como uma string simples e deve corresponder ao valor 'comm' inteiro (também existe uma opção --regexp para alterar isso). O killall possui as opções --interactive e - younger-than, que o pkill não possui.

Também existe um killall5 dos dias SysV e foi portado para outras variantes do UNIX (supostamente no pacote do Ubuntu 'sysutils'). Isso se comporta de maneira diferente à moda antiga. Isso costumava ser usado internamente nos scripts init para desligar ou mudar para o modo de usuário único.


2
Não, nem pkillnem killalldeve ser usado em scripts, apenas de forma interativa e com cautela.
Geirha
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.