status=200/CHDIR: systemd は OpenVPN を起動していなかった

サービスが失敗し、ログには spawn とディレクトリが登場し、最初の反応は VPN 設定の確認です。そのファイルはまだ何も読まれていません。systemd はプロセスの準備中、実行ファイルが動く前に失敗したので、パーサーも証明書もリモートホストも参照されていません。ステータスコードを OpenVPN ではなく systemd についての記述として読むことが、これを短い調査に変えます。

アプリケーションより先にステータスコードを読む

サービス名の後の数字コードが、失敗した段階を示します。ディレクトリの失敗は CHDIR ステータスとして報告されますが、実行できなかった実行ファイルはまったく別のコードです。要約行では似て見えても、原因には何の共通点もありません。

この区別が重要なのは、修正箇所が別のファイルにあるからです。CHDIR の失敗はパスとサービスからの見え方の問題です。exec の失敗はバイナリ、そのインタープリター、あるいは無関係なマウントの問題です。VPN のリモート、暗号リスト、証明書パスを変えても、どちらも解決しません。

失敗が起動時であり、成功した動作の後ではないことを確認してください。昨日は動いていたサービスが同じ段階で失敗するなら、ディレクトリ、その権限、あるいは unit 自体が変わったのであり、その変化こそ探すべき証拠です。

unit にどこにいたいのか尋ねる

インストールされていると思うファイルではなく、有効な unit を読んでください。drop-in はメインの unit を編集しなくても作業ディレクトリを上書きできるからであり、show の出力は問いに直接答えます。

systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30

upstream サーバーのテンプレートでは、作業ディレクトリはサーバー設定ディレクトリで、インスタンス名がその中のプロファイルを選びます。したがって branch という名前のインスタンスは同じディレクトリに自分のファイルを期待し、別の場所に置かれたプロファイルは作業ディレクトリの要件をまったく満たしません。

unit が要求するものと存在するものを比べてください。かつて存在したパス、今は別の場所を指すシンボリックリンク、ディレクトリと一致しなくなったインスタンス名は、どれもこの失敗を生む普通の変化です。

サービスから見えるとおりにパスを確認する

あなたのシェルとサービスは同じファイルシステムの見え方を共有していません。設定されたルートディレクトリや root image は unit 内での絶対パスの意味を変え、ホストに明らかにあるパスがその名前空間にないこともあります。手動テストを信じる前に unit の設定を読んでください。

権限が問題を悪化させます。サービスは特定のユーザーとして動作し、そのユーザーは目標に到達するためにすべての親ディレクトリを通過できる必要があり、目標そのものを読めるだけでは足りません。root には読めるがサービスのユーザーには通過できないディレクトリは、パスが存在しないように見える失敗を生みます。

namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths

ハードニング設定もこの絵の一部です。ホームディレクトリを隠す、あるいはファイルシステムの一部を読み取り専用にする unit は設定どおりに動いており、作業ディレクトリは sandbox がまだ公開している場所にある必要があります。

所有者を直し、次は別のエラーを予期する

レイアウトや unit を、その設定を所有する担当者を通じて修正してください。プロファイルを期待されたディレクトリに移すのはレイアウトが誤っているときの正当な修正ですが、入れないディレクトリを説明はしません。一般的な答えとして扱わないでください。

設定ツリーの権限を広げる、あるいは sandbox を外すという近道に抗ってください。どちらも症状を消す一方で、意図的に置かれた保護を取り除き、次の失敗は解釈しにくくなります。

成功を仮定せずにインスタンスを再起動し、次のイベントを読んでください。次に起こりそうなエラーは OpenVPN が設定ファイルを開けないことで、これは前進です。作業ディレクトリに入り、パーサーが動いています。そこから unit の実際のファイルマッピングを追い、ネットワークのトラブルシューティングに戻らないでください。

systemd の実行リファレンスは、作業ディレクトリがルートディレクトリや sandbox とともにどう解釈されるかを定義しています。覚えておくべき型は単純です。各ステータスコードは別の段階を示し、アプリケーション自身のエラーだけがアプリケーションを説明します。