Squid shm_open の権限エラー：共有メモリの所有者を確認する

Could not read pid file と shm_open(...): Permission denied は、同じ Squid の起動失敗で同時に現れることがあります。両者は別のリソースを指しています。キャッシュディレクトリの所有者を直しても、どちらも単独では解決しません。

Linux では、POSIX の共有メモリオブジェクトは通常 /dev/shm の下に表されます。その所有者とアクセスモードが重要です。別の実行アイデンティティが残したオブジェクトは、squid.conf が読めていて待ち受けポートが空いていても、後続のプロセスを失敗させることがあります。

このインスタンスの起動経緯を再現する

通常のサービス起動と、切り分け中に行った手動起動を比較します。手動で起動したプロセスとパッケージのサービスでは、ユーザー、パス、設定ファイルが異なる場合があります。オブジェクトを古いものと判断する前に、別の Squid インスタンスがまだ動作していないかを確認します。

次に、失敗している正確な操作を読みます。PID のエラーは設定された PID の場所とその親ディレクトリに関わります。ログのエラーはログファイルまたはディレクトリに関わります。キャッシュ初期化のエラーはストレージに関わります。shm_open のエラーは名前付きの共有メモリオブジェクトに関わり、プロセスに適用されるセキュリティポリシーが関係する場合もあります。

リソースごとに、必要な実行時アクセスと現在の所有者・モードを比べます。通常のパーミッションが足りているように見えるなら、SELinux や AppArmor の拒否記録を確認します。“Permission denied” だけでは、どの層がアクセスを拒否したかは分かりません。

二次的な問題を生まずに所有者を修正する

実行アカウントはインストールのサービス設定と一致させます。すべてを nobody に切り替えると、補助プログラムのアクセスが壊れ、サービスが管理するファイルとの新たな不整合を招きます。

/dev/shm 内の Squid らしいオブジェクトを全部削除するのも良い第一手ではありません。名前付きオブジェクトは稼働中のインスタンスのものかもしれません。必要な掃除は、影響を受けるサービスを停止した状態で、放棄が確認できたリソースだけを対象にし、その後は通常のサービス機構で起動します。

有用な結果は、一貫した起動と所有者のモデルです。エラーが消えるまで root で単発のコマンドを実行すると、次の定例の再起動にまったく同じ問題を残すことがあります。