systemctl が systemd は PID 1 ではないと言う：では次に何を？

「systemctl start openvpn-client@office」を実行して、システムが systemd で起動されていないというメッセージが出ると、サービス障害のように見えます。しかしこれはサービス障害ではまったくありません。呼び出した systemctl が、話す相手となる動作中のマネージャーを見つけられないので、OpenVPN については何も調べられていないのです。 sudo はマネージャーを作らず、unit ファイルをインストールしても同じです。コマンドとマシンは別の世界から来ており、このすれ違いが現れたのはエラーだけでした。

まず、コマンドを実行している場所で PID 1 を所有しているプロセスは何かを確認してください。その答えが、unit がそもそも存在するかどうかを決めます。

エラーが示すのは OpenVPN ではなく環境

systemctl はマネージャーではなくクライアントです。ソケット経由でシステムマネージャーに接続し、相手側にマネージャーがいなければ、フォーラムに貼られるあのメッセージを出力します。 ps -p 1 -o pid=,comm= は実際に何が PID 1 として動いているかを示し、その答えは多くの場合シェル、init のラッパー、あるいはコンテナ自身のエントリポイントです。その状況では、unit ファイルが完全に正しくても一度も読まれないことがあります。root でコマンドを繰り返しても、変わるのはクライアントの資格情報だけです。

最初の行より前にメッセージ全体を読んでください。unit が見つからない、条件が満たされないといったマネージャー自身からのエラーなら、マネージャーには到達しています。このエラーは、到達していないことを意味します。

WSL：systemd の有効化は設定変更

WSL は後のリリースで systemd のサポートを獲得しましたが、この機能はディストリビューションごとに有効化され、インストール済みの WSL バージョンが対応している場合にだけ働きます。 wsl --version は Windows 側で何を持っているかを示し、ディストリビューションの /etc/wsl.conf には [boot] セクションがあり、そこに systemd=true を書きます。既存のセクションを消さずにそのファイルを編集し、変更を反映させるために WSL インスタンスを再起動してください。 wsl --shutdown は実行中のすべてのディストリビューションを停止するので、先に作業を保存してください。

再度開いたら、OpenVPN の unit に触る前にマネージャーを確認します。 ps -p 1 -o comm= が systemd と表示するはずです。systemd を有効にしてもプロファイル、資格情報、インスタンス名は提供されないので、次のエラーは PID 1 ではなくこれらのいずれかに関するものになります。

コンテナが動かすのは unit ではなくエントリポイント

通常のコンテナは、エントリポイントやコマンドが指定したものを起動し、どのパッケージを入れても systemd で起動したマシンにはなりません。イメージに systemctl を加えても、接続先のないクライアントが手に入るだけです。Community OpenVPN でサポートされる形は通常、フォアグラウンドで動くプロセスで、 openvpn --config /path/to/client.conf のようにエントリポイントから起動し、外側から監督します。その所有者が起動、シグナル、停止を受け持ち、トンネルを管理する唯一の存在であるべきです。

そのトンネルをすでに管理しているエントリポイントの隣で、対話的なコピーを起動してはいけません。 二つのプロセスがデバイスとルートを奪い合う からです。コンテナ内の最小限の init プロセスは子プロセスを回収してシグナルを転送しますが、イメージを unit を持つホストに変えるわけではありません。

デプロイが本当にコンテナ内で systemd を必要とするなら、そのために意図して設計されたイメージが必要です。 systemctl が文句を言わなくなるまで特権を足していくのではありません。

マネージャーが存在してから次のエラーを読む

本物のマネージャーがサービスを起動してからが、役に立つエラーの始まりです。デバイス権限の失敗、設定の解析エラー、資格情報の欠落、到達できないピアは、PID 1 のメッセージが一度も試さなかった四つの別問題です。unit が生み出した順に、 journalctl -u openvpn-client@office -n 50 を systemd ホストで使うか、マネージャーのない場所でクライアントをフォアグラウンドで動かして読んでください。フォアグラウンドでの実行は、プロファイル自体が機能するかを確認する最速の方法でもあります。

メモでは二つの環境を分けてください。トンネルを動かすホストと、コマンドを入力する場所です。