-.mount ユニットがマスクされています: OpenVPN クライアントが起動しません

サービスは OpenVPN が動き出す前に失敗し、エラーは設定した覚えのないマウントユニットについて語っています。これが手がかりです。ルートマウントのユニットがマスクされているため systemd がトランザクション全体を拒否しており、VPN プロファイルはまだ読まれていません。よくある原因は実行時ユニットのディレクトリに残ったファイルで、壊れた fstab でも証明書の欠落でもありません。まずファイルを追ってください。除外するのが最も安価な説明です。

エラーが示すのはルートマウントで、あなたのプロファイルではありません

systemd はカーネルのマウント情報からルートマウントのユニットを自分で生成し、そのユニットを -.mount と名付けます。ハイフンがルートパスを表すからです。このユニットは通常メモリ上にしか存在せず、背後にファイルはありません。エラーがマスクされていると言うとき、誰かが systemd の読み込む場所にユニットファイルを置き、そのファイルを /dev/null に向けています。マスクは実際の状態であり、メッセージの打ち間違いではありません。

インスタンスのユニットが失敗するのは、ジョブグラフが順序づけと自身のマウント要件を通じてルートマウントに到達するからです。トランザクションは OpenVPN のバイナリが実行される前に拒否されるので、クライアントの設定側に原因はありません。だからプロファイルや証明書、認証情報を変えても、この特定の失敗には効きません。

OpenVPN をデバッグする前に実行時のディレクトリを確認してください

実行時ユニットのディレクトリで、その名前と完全に一致するファイルを探し、そのうえで systemd にユニットが何だと考えているかを尋ねてください。どちらの答えもすぐに出て、合わせれば残ったファイルと本当のマウント問題を切り分けられます。

ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount

普通のマシンにそのファイルはなく、マスク済みの一覧にルートマウントは含まれません。最初のコマンドが /dev/null へのシンボリックリンクを表示すれば、診断は確定です。同じディレクトリには同じ道具が作った tmp.mount のマスクもあることがあり、それは別の名前で同じ種類の失敗を生みます。エラーに出た名前だけでなく、ディレクトリ全体を見てください。

ls -la /run/systemd/system/*.mount

ディレクトリがきれいで、それでもユニットがマスクされているなら、マスクは検索パスの別の場所にあり、systemctl cat -.mount がどのファイルを読み込んでいるかを示します。

ファイルを削除して、再読み込みし、もう一度起動してください

実行時のファイルを消してマネージャーを再読み込みすれば足り、パッケージ由来のものには触れません。起動の前に再読み込みしてください。systemd はディレクトリを読み直すまで、読み込み済みのユニット状態を保持します。

sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]

そのあとは、直ったと決めつけずにサービス自身のジャーナルを読んでください。きれいな起動は systemd がユニットを受け入れたことしか証明しません。クライアントは設定の欠落、到達できないピア、検証できない証明書で依然として落ちます。それらはマスクされたユニットの陰に隠れていた普通の OpenVPN の問題です。ジャーナルには、どのプロファイルが読まれ、トンネルが実際に確立したかが記録されます。ユニットは起動してトンネルが張られないなら、別の問題に移ったということで、それは前進です。

journalctl -u [email protected] -b --no-pager

/run は一時的なファイルシステムなので、再起動でもファイルは消えます。つまり再起動は有用なテストになります。再起動後に動き、次の配備のあとにまた失敗するなら、そのファイルはイメージに焼き込まれています。

イメージから戻ってこないようにしてください

ビルド時にマウントユニットをマスクするコンテナや仮想マシンのテンプレートは、そのマスクをすべてのクローンに持ち込みます。次にファイルシステムを必要とするものが壊れ、メッセージは由来のイメージではなくマウントを責めます。動いているひとつのインスタンスの中で直しても、次のインスタンスが作られるまで問題は隠れたままです。

ビルドのコンテキストでファイル名とそれを作るコマンドを探し、テンプレートからマスクを外して作り直してください。ビルド中に本当にマスクが必要なら、ビルドを終える同じレイヤーで外し、出荷されるイメージがきれいに起動するようにします。手で直したマシンではなく、新しいクローンで検証してください。イメージが変わったことを示せるのはその試験だけです。

覚えておくべき症状はエラーと設定していたもののずれです。VPN クライアントを起動している最中に systemd がマウントの不満を言うときは、まずメッセージのユニット名を読み、そのあとにサービス名を読んでください。