Matar o processo pelo fusor em vez do pidfile?

A fuseropção de 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 para ser muito portátil.

E pelo menos no Debian, o fusercomando está no psmiscpacote, que foi designado como "opcional" e, portanto, não se pode esperar que esteja sempre presente em todos os sistemas.

Existem dois problemas potenciais com essa abordagem que vêm à mente além do que 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 devem definir a opção) se liguem à mesma porta e descarreguem o balanceamento de carga de conexões tradicionalmente feitas por um processo mestre para o kernel.

Os dois problemas potenciais que vêm disso são:

• Para servidores que usam paralelismo baseado em processos (NGinx por exemplo) e usam esta opção, os PID's que estão conectados ao soquete geralmente serão filhos do processo principal, e não do processo principal em si. Em tal situação, sua fuserabordagem matará todos os filhos, mas não enviará nenhum sinal para o processo principal, o que pode não encerrar o serviço (se o processo principal apenas reiniciar os filhos) ou pode resultar em seu desligamento de uma maneira que cause problemas (o código pode assumir que a morte do processo filho indica um erro fatal e usar um caminho de saída diferente do que usaria se o processo principal tivesse recebido o próprio sinal).

• Isso pode matar outros programas do que você deseja. Esse caso não é muito provável que seja uma coisa ruim (sobre os únicos 'outros' programas que você pode matar são coisas que provavelmente são malware), mas vale a pena considerar.