NTPsec が再起動後に自動起動しない問題の調査と解決

背景

複数の環境において NTPsec を導入し運用していたが、ConoHa VPS 上の Debian 13 環境でのみ、再起動後に NTPsec が自動起動しない事象が発生した。
導入手順としては以下を実施した。

手動で起動すれば正常に稼働し、ntpq -pn により同期も確認できた。
しかしサーバーを再起動すると ntpsec.service が inactive (dead) のままとなり、

と表示される状態に陥った。
他の環境（オンプレミス Debian、別クラウド環境など）では同じ問題は再現せず、ConoHa VPS の Debian 13 特有の現象であると判明した。

目的

サーバー再起動後も NTPsec が確実に自動起動するようにし、NTP が停止している状態を放置せぬことを目的とした。

調査過程

1) サービス状態の確認
systemctl status ntpsec は常に inactive (dead) を示した。
journalctl -b | grep -i ntp にも Starting ntpsec.service の記録が存在せず、起動試行そのものが行われていないことが判明した。

2) ユニット定義の精査
/usr/lib/systemd/system/ntpsec.service には ConditionCapability=CAP_SYS_TIME および Conflicts=systemd-timesyncd.service が記載されていた。
この条件により、環境依存で systemd が起動をスキップする可能性があると推定された。

3) 起動方式の問題
ExecStart は ntp-systemd-wrapper を呼び出し、Type=forking による PIDFile 監視を行っていた。
ネットワーク準備や PIDFile の生成タイミングに依存するため、静かに失敗する余地が存在した。

4) 補助ユニットの存在
ntpsec-systemd-netif.path や ntpsec-wait.service が存在し、ネットワーク状態により起動制御を行う構造であった。
ConoHa VPS (ifupdown ベース) 環境ではこれらのトリガが発火せず、結果として起動が抑止されていたと考えられる。

解決方法

純正の ntpsec.service を利用することを断念し、独自の systemd ユニットを作成した。
ntpd を前面常駐（-n）で起動させ、systemd が直接プロセスを監視する方式とした。

次の手順で独自ユニットを有効化する。

このユニットを有効化することで、再起動後も確実に ntpd が起動し、数十秒待てば ntpq -pn に * マークが付いて同期が確認できるようになった。

決定した運用

• ConoHa VPS 上の Debian 13 環境では myntp.service を採用し、純正の ntpsec.service は mask したままとする。
• 他環境では純正の ntpsec.service が正常に動作しているため、そのまま利用を継続する。
• 監視として ntpq -pn を定期的に実行し、同期状態を確認する。
• transitional パッケージ（ntpdate 等）は削除し、混乱を避ける。

まとめ

本件は ConoHa VPS 上の Debian 13 環境に特有の現象であり、純正の ntpsec.service が systemd の条件判定やネットワーク依存トリガにより起動をスキップされていたことが原因である。
他の環境では再現せず、環境依存の強い問題であった。

解決策としては、複雑なラッパーや条件を排し、ntpd を単純に foreground 起動させる独自ユニットを作成することで、安定して自動起動を実現できた。

この事象から得られる教訓は、「systemd ユニットが複雑な条件や補助ユニットに依存している場合、環境によっては起動が成立しないことがある。必要最小限の構成に立ち戻ることが安定稼働につながる」 という点である。