最近、プロセスを終了する習慣がありました。
fuser -k -n tcp $PORT
これにより、間違ったプロセスを終了することが困難になります。私はまだ存在するかもしれないし、存在しないかもしれない、正しいpidを含むかもしれないし、含まないかもしれないpidファイルを操作するよりもこれを好みます（良い、ここでは少し劇的です:-)
しかし、私が誤って見つけた一般的な停止スクリプトはまだpidfileを使用しています。
pidfileメソッドの重要な機能が欠落しているか、fusionの無効な機能がありませんかapproach？私の推測ではfuser使用できないということです。検索エンジンの結果から、bsd、debian、suse、centos、aix、Solarisなどが利用可能に見えます。
答え1
コマンドfuserオプションは-n <file|udp|tcp>Linuxにのみ適用されますが、PIDファイルベースのソリューションは多くのUnixバリアントでは伝統的であるため、移植性に優れています。
少なくともDebianでは、コマンドは「オプション」として指定されたパッケージfuserにあるため、すべてのシステムに常に存在するとは予想できません。psmisc
答え2
TelcoMが述べたことに加えて、このアプローチには2つの潜在的な問題があります。どちらもソケットオプションに関連していますSO_REUSEPORT。
このソケットオプションを使用すると、複数のプロセス（すべてのプロセスにこのオプションを設定する必要があります）が同じポートにバインドされ、プライマリプロセスで従来行われていた接続のロードバランシングをカーネルにオフロードできます。
これによって発生する2つの潜在的な問題は次のとおりです。
プロセスベースの並列処理（NGinxなど）を使用し、このオプションを使用するサーバーの場合、ソケット接続のPIDは通常、基本プロセス自体ではなく、基本プロセスの子プロセスです。この場合、アプローチ
fuserはすべての子プロセスを終了しますが、基本プロセスにシグナルを送信しないため、サービスがまったく終了しない場合（基本プロセスが子プロセスを再起動した場合）、サービスが終了する可能性があります。問題を引き起こす方法（コードは、子プロセスの終了が致命的なエラーを示すと仮定し、基本プロセス自体がシグナルを受け取った場合とは異なる終了パスを使用できます）。これにより、必要な他のプログラムが終了する可能性があります。このシナリオは悪いわけではありませんが（削除できる唯一の「他の」プログラムはマルウェアかもしれません）、考慮する価値があります。