Ubuntuの自動更新でVPSは再起動するか：unattended-upgradesの既定値

運営・編集: VPS運用ノート編集部（編集方針）

Ubuntu 24.04のVPSは、unattended-upgradesが入っていれば毎日セキュリティ更新を自動で入れる。ただしOSの再起動は既定では行わない。カーネルなどの更新で再起動が必要になると/var/run/reboot-requiredというファイルが作られ、再起動するまでそのまま残る。

自動で再起動させたいときはAutomatic-Rebootを"true"にし、Automatic-Reboot-Timeで時刻を指定する。この時刻はサーバーのタイムゾーンで読まれるので、UTCのままのVPSで"02:00"と書くと日本時間の11時になる。

2026年10月9日に、Ubuntu 24.04のコンテナにunattended-upgradesを入れ、設定ファイルの既定値と確認コマンドの出力を見た。Docker再起動後にコンテナは戻るかの前に、OSがいつ再起動するのかを決めるための記録として残す。

確かめた環境と方法

• コンテナ: Docker Hubのubuntu:24.04（2026年10月9日に取得）。unattended-upgrades 2.9.1+nmu4ubuntu1、apt 2.8.3、needrestart 3.6-7ubuntu4.5
• 見たもの: /etc/apt/apt.conf.d/の50unattended-upgradesと20auto-upgrades、apt-daily.timerとapt-daily-upgrade.timerのユニットファイル、unattended-upgrade --dry-run --debugの出力、/usr/bin/unattended-upgradeの再起動の処理、apt-config dumpの出力

VPS事業者が配っているOSイメージそのものではない。事業者のイメージは設定を変えていることがあるので、自分のVPSでも下の「VPSで確かめるコマンド」を実行してほしい。OSの再起動そのものも試していない。

既定値は「毎日入れるが、再起動しない」

Ubuntu公式のドキュメントも、unattended-upgradesは既定で入っていて、インストール直後からセキュリティ更新の自動適用が有効になると説明している。noble-updatesも入れたいときは、設定ファイルの該当行のコメントを外す。

--dry-run --debugの出力の「Allowed origins are:」はo=Ubuntu,a=noble, o=Ubuntu,a=noble-security, o=UbuntuESMApps,a=noble-apps-security, o=UbuntuESM,a=noble-infra-securityだった。

更新が走るのは、サーバーの時刻で6時台

更新を入れるのはapt-daily-upgrade.timerで、ユニットファイルはOnCalendar=*-*-* 6:00、RandomizedDelaySec=60m、Persistent=trueだった。サーバーの時刻で毎日6:00から7:00の間のどこかで動く。Persistent=trueなので、その時刻にサーバーが止まっていた日は、起動した後に実行される。パッケージ一覧の取得はapt-daily.timerで、6:00と18:00から最大12時間ずれて動く。

確かめたコンテナのタイムゾーンはUTCだった。タイムゾーンがUTCのVPSでは、6:00は日本時間の15:00になる。この状態でAutomatic-Rebootだけを"true"にすると、時刻が既定のnowなので、再起動が必要な更新が入った日は、日本時間の15時から16時ごろの更新の直後に再起動する。昼間に使うn8nやWebhookの受け口なら、時刻も一緒に決める。

自動で再起動させる設定

50unattended-upgradesを直接書き換えるより、番号の大きい別ファイルに書く方が後で差分を追いやすい。aptは/etc/apt/apt.conf.d/のファイルを名前の順に読むので、後に読まれたファイルの値が使われる。

# /etc/apt/apt.conf.d/52unattended-upgrades-local
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "18:30";

コンテナで上の2行（時刻は"03:30"で試した）を52unattended-upgrades-localに書き、apt-config dump | grep Automatic-Rebootを実行すると、書く前は何も出ず、書いた後は2行とも出た。

時刻を決める手順は次のとおり。

1. timedatectlの「Time zone」を見る。
2. UTCなら、日本時間の3:30はUTCの18:30なので"18:30"と書く。タイムゾーンをsudo timedatectl set-timezone Asia/Tokyoで変えて"03:30"と書く方法もあるが、cronの時刻やログの時刻も日本時間に変わる。どちらにするかは、cronやアプリの設定と合わせて決める。
3. 再起動はunattended-upgradesが/sbin/shutdown -r <時刻>を呼んで予約する（/usr/bin/unattended-upgradeの処理で確認）。予約が入ったかはshutdown --showで見られる。

Automatic-Reboot-WithUsersは既定でtrueなので、SSHでログインして作業している最中でも予約の時刻に再起動する。作業中の再起動を避けたいなら"false"にするか、作業する時間帯と再起動の時刻をずらす。作業の時間帯は更新の作業時間を決める担当表に書いておく。

Dockerは既定の対象外、Docker側の再起動も別に考える

Docker公式の手順でDocker Engineを入れた場合、パッケージの取得元はdownload.docker.comになる。このリポジトリのReleaseファイルはOrigin: Docker、Label: Docker CEで、上のAllowed-Originsに含まれない。既定のままでは、docker-ceはunattended-upgradesでは更新されない。Docker Engineの更新は、自分で日時を決めてaptで入れる。

更新の後に古いライブラリを使っているサービスを再起動するneedrestartは、既定の設定ファイル（/etc/needrestart/needrestart.conf）にqr(^docker) => 0と書かれていて、dockerで始まるサービスを自動で再起動する対象から外していた。除外は名前がdockerで始まるサービスだけで、containerd.serviceのような別の名前のサービスは含まれない。事業者のイメージでは設定が変わっていることもあるので、needrestartが入っているVPSでは/etc/needrestart/needrestart.confを自分でも確かめる。

OSの再起動が起きると、コンテナはrestart設定のとおりにしか戻らない。restart:が未設定（no）のコンテナは止まったままになる。再起動の時刻を決めたら、restart設定ごとの結果を見て、戻したいコンテナにunless-stoppedかalwaysが入っているかも確かめる。

VPSで確かめるコマンド

/var/run/reboot-requiredがあるのに自動再起動を使わない場合は、再起動する日時を自分で決める。いつ止めてよいかを決める担当表は更新の作業時間、止まった後に処理が戻ったかを知る方法は監視と通知の検証に書いた。

参考資料（確認日: 2026年10月9日）

• Ubuntu Server documentation: Automatic updates
• Ubuntu Manpage: shutdown(8)（Ubuntu 24.04）
• Docker Docs: Install Docker Engine on Ubuntu
• Docker公式リポジトリのReleaseファイル（Ubuntu 24.04）
• Docker Docs: Start containers automatically

1. cat /etc/apt/apt.conf.d/20auto-upgrades で自動更新が有効か見る
2. apt-config dump で Automatic-Reboot と Automatic-Reboot-Time の今の値を見る
3. timedatectl でサーバーのタイムゾーンを見る
4. systemctl list-timers apt-daily-upgrade.timer で次に更新が走る日時を見る
5. sudo unattended-upgrade --dry-run --debug で対象の取得元と入る更新を見る