Recentemente desenvolvi o hábito de matar processos com
fuser -k -n tcp $PORT
que dificilmente pode matar o processo errado. Eu prefiro isso mais mexer com um pidfile que pode ou não estar ainda lá ou pode ou não pode conter o pid correto (OK, eu sou um pouco dramático aqui: -)
No entanto, o típico script de parada que eu tropeço ainda usa um pidfile.
Estou perdendo um recurso importante da abordagem pidfile ou um erro de ajuste do fusor approach . Meu melhor palpite é que fuser não está disponível. Apesar de julgar pelos resultados do mecanismo de busca, o bsd, o debian, o suse, o centos, o aix, o solaris, todos parecem tê-lo.
A opção fuser do comando -n <file|udp|tcp> é específica do Linux, enquanto a solução baseada em arquivo PID é tradicional em muitas variantes do Unix e, portanto, é garantida como muito portátil.
E no Debian, pelo menos, o comando fuser está em psmisc package, que foi designado como "opcional", e portanto não se pode esperar que ele esteja sempre presente em todos os sistemas.
Existem dois possíveis problemas com essa abordagem que vêm à mente além do que a telcoM mencionou, e ambos têm a ver com uma opção de soquete chamada SO_REUSEPORT .
Essa opção de soquete permite que vários processos (todos os quais precisam definir a opção) sejam vinculados à mesma porta e descarreguem o balanceamento de carga de conexões tradicionalmente feitas por um processo mestre para o kernel.
Os dois possíveis problemas decorrentes disso são:
Para servidores que usam paralelismo baseado em processo (NGinx por exemplo) e usam essa opção, os PIDs que estão conectados ao soquete geralmente são filhos do processo principal e não do processo principal em si. Em tal situação, sua abordagem fuser irá matar todos os filhos, mas não enviará nenhum sinal para o processo principal, que pode não terminar o serviço (se o processo principal apenas reinicia os filhos), ou pode resultar nele sendo encerrado de uma maneira que causa problemas (o código pode assumir que o processo filho que está morrendo indica um erro fatal e usar um caminho de saída diferente daquele que teria se o processo principal tivesse recebido o sinal em si).
Isso pode matar outros programas além do que você deseja. Tal caso não é muito provável que seja uma coisa ruim (sobre os únicos programas 'outros' que você pode matar são coisas que são provavelmente malware), mas é difícil considerar.