StackOverflowには素晴らしい答えがあります。デーモンに対してより良いロックを提供（で合成エドゥアルド・フリリ）はデーモンプロセスに依存しない汎用PIDファイルロック機構です。 PIDロックファイルが時々問題を引き起こす理由についての良い意見がたくさんあるので、ここでは繰り返しません。
つまり、ソリューションは、デーモンがSIGKILLされた後も持続するファイルに依存するのではなく、名前でソケットを追跡するLinux抽象名前空間ドメインソケットに依存します。この例では、プロセスが終了するとLinuxがソケットを解放するように見えます。
しかし、バインディングプロセスがSIGKILLとマークされている場合、Linuxが抽象ソケットを使用して正確に何をしているかを説明する明確な文書はLinuxにありません。知っている人はいますか？
つまり、抽象ソケットが再利用するために正確にいつリリースされるのですか？
問題が完全に解決されない限り、PIDファイルメカニズムを抽象ソケットに置き換えたくありません。
ベストアンサー1
私はこの質問を1年前に投稿しましたが、明確な文書が不足して不満がありました。アップデートがあるかどうか、Linuxドキュメントをもう一度確認する必要があると思いましたが、今行ってもいいです。これを見て:
抽象ソケット
ソケット権限は抽象ソケットに対して意味がありません。プロセスumask（2）は抽象ソケットをバインドすることに影響を与えず、オブジェクトの所有権と権限の変更（fchown（2）とfchmod（2）を介して）は抽象ソケットには影響しません。効果。ソケットのアクセシビリティ。
ソケットへのすべてのオープン参照が閉じられると、抽象ソケットは自動的に消えます。
返品、Linuxプログラミングインターフェース渡すマイケルクリーク扱う問題（クロスポスト）この他の答え):
57.6 Linux抽象ソケット名前空間
いわゆる抽象名前空間は、ファイルシステムに名前を生成せずにUNIXドメインソケットを名前にバインドできるLinux固有の機能です。これはいくつかの潜在的な利点を提供します。
- ファイルシステム内の既存の名前との競合の可能性について心配する必要はありません。
- 使用が終わったら、ソケットパス名を切断する必要はありません。ソケットが閉じると、抽象名は自動的に削除されます。
- ソケットのファイルシステムパス名を作成する必要はありません。これは、chroot環境またはファイルシステムへの書き込み権限がない場合に便利です。
抽象バインディングを生成するには、最初のバイトを指定します。 ソーラーパスフィールドはNULLバイト（\ 0）です。 [...]
@ user3188445の答えと一緒に、これは質問を非常に正確に説明すると思います。
つまり、SIGKILLプロセスが開いているすべてのソケットを閉じるという仮定がまだ存在します。これは合理的な仮定のように見えますが、この動作を定義する文書はありません。