Debian 系の環境で apt upgrade を実行したとき、アップグレード対象があるはずなのに「保留（kept back / 保留されます）」と表示され、いつまでも残り続けることがある。
この現象は「壊れている」場合もあれば、apt の設計として「安全側に倒れて止めている」だけの場合もある。
本稿では、保留が発生する仕組みを一般化して整理し、原因と影響、対応策と今後の運用方針を、実務で判断できる粒度でまとめる。
1. 現象
apt upgrade の実行後に、次のような出力が出る。
1 2 3 4 5 | $ sudo apt upgrade ... 以下のパッケージは保留されます: PACKAGE-A PACKAGE-B アップグレード: 0 個、新規インストール: 0 個、削除: 0 個、保留: 2 個。 |
重要なのは、ここでいう「保留」は apt が「更新が存在しない」と言っているのではなく、
「この実行（apt upgrade のポリシー）では進めない更新がある」と言っている点である。保留の意味合いは文脈で変わりうるが、
典型的には「新規依存の追加」や「既存パッケージの削除」が必要になる更新が止められている。[1][2]
2. 仕組み
apt upgrade は、基本的に「安全側」に寄せた更新コマンドとして扱われることが多い。
具体的には、依存関係の変化によって「新しいパッケージを追加で入れる必要がある」「別のパッケージを削除する必要がある」といった状況になると、
その更新を適用せずに保留として残す場合がある。[1][8]
本稿はコマンドを apt upgrade に統一するため詳述は避けるが、apt には依存関係の変化をより積極的に解決する系統の操作も存在する。
ただし「何でも通す」ことは安全性とトレードオフなので、保留が出たときに “なぜ止まったか” を理解してから選択するのが運用として安定する。
さらに、保留には「ユーザーが明示的に固定している」ケースもある。たとえば apt-mark hold によりパッケージが hold に設定されていると、
apt upgrade に限らず自動的な更新が抑止される。[3][4]
3.原因
保留の原因は 1 つではない。実務上は、次の順で切り分けるのが早い。
原因 1: 更新に「新規依存の追加」または「削除」が必要
パッケージが更新される過程で依存関係が変わり、従来は不要だった別パッケージが新たに必要になったり、
逆に競合回避のために別パッケージの削除が必要になったりする。この場合、apt upgrade は安全側の判断として更新を適用せず、保留として残すことがある。[1][2]
原因 2: リポジトリの整合が一時的に崩れている
ミラーが完全に同期していない、あるいは複数の系列（例: 更新ポケットや外部リポジトリ）が混在しており、
必要な依存パッケージが「その時点では」取得できないケースがある。この場合も apt は破壊的な状態を避けるため、保留として止める。[5][6]
原因 3: パッケージが hold（固定）されている
apt-mark hold により対象パッケージが固定されていると、アップグレードは抑止され、保留として残り続ける。運用上、意図的に固定している場合もあれば、
過去のトラブル回避のために残した hold を忘れている場合もある。[3][4]
原因 4: 段階的配布やポリシーによる遅延
ディストリビューションや環境によっては、更新が段階的に配布され、ある時点では「保留に見える」期間が生じることがある。
この場合、時間経過で自然に解消されることもある。[7]
4. 影響
原因の種類によって影響も変わるが、保留が「放置可能なノイズ」にならないのは、次の理由による。
- セキュリティ更新の取りこぼし：保留が重要パッケージに及ぶと、脆弱性修正が適用されずに残る可能性がある。
- 更新状態の不透明化：定期メンテナンスのログに「保留」が残り続けると、異常と正常の判別がつきにくくなる。
- 依存関係の負債：保留を続けると、後日まとめて依存変更が襲ってきて差分が大きくなり、結果として事故確率が上がる。
- 運用手順の分岐：保留がある環境とない環境で手順が揺れ、再現性（Runbook の単純さ）が損なわれる。
5. 対応策
対応は「その場の解消」と「再発しにくい運用」の両輪で考える。
まずは “保留になっている理由” を確認し、想定内か想定外かを切り分けるのが先決である。
1) 何が保留されているかを把握する
apt upgrade の出力に出るパッケージ名を記録し、そのパッケージが「本体」なのか「依存を束ねるメタ」なのかを把握する。
特に、メタパッケージは “依存先が増える更新” を引き起こしやすく、apt upgrade の方針と衝突しやすい。[1]
2) hold の有無を確認する
意図せず hold が残っていると永遠に解消しない。まず固定があるかを確認し、意図に合わなければ解除する。[3][4]
1 2 | apt-mark showhold sudo apt-mark unhold PACKAGE; |
3) リポジトリの整合（同期/混在）を疑う
ミラーの同期遅延や外部リポジトリ混在が疑われる場合、時間を置いて再実行する、またはリポジトリ構成を見直す。
「依存がまだ来ていない」だけなら自然に解消することがある。[5][6]
4) 保留を許容するかどうかをルール化する
保留が段階的配布や安全確認待ちに起因する場合、放置が合理的なこともある。
一方で、サーバ運用では “放置してよい保留” と “放置してはいけない保留” を区別する基準が必要になる。[7]
対応策一覧（メリット・デメリット）
| 対応策 | 概要 | メリット | デメリット |
|---|---|---|---|
| hold の確認と解除 | apt-mark showhold で固定を見つけ、意図しないものを解除する | 原因が明確で、効果が確実。恒久的に解消しやすい | 意図して固定していた場合、解除で更新が一気に走る可能性がある |
| 時間を置いて再実行 | ミラー同期や依存公開待ちの場合に、待って apt upgrade を再実行する | 構成変更なしで済む。安全側で自然解消を狙える | いつ解消するかが読めない。重要更新の遅延が起きうる |
| リポジトリ構成の点検 | 外部リポジトリ混在、優先度、ミラーの問題を潰す | 根治に近い。以後の更新の一貫性が上がる | 原因調査に時間がかかる。誤ると別の不整合を呼ぶ |
| 保留の許容ルール化 | 許容/非許容を定義し、検知・通知の判断を固定する | 運用が揺れない。監視・通知と相性が良い | 初期設計が必要。例外が出るとルール更新が必要 |
6. 運用方針
保留は “発生し得る前提” で、運用として吸収するのが現実的である。
重要なのは「保留が出たときに人間がどう判断し、どこまで自動化するか」を先に決めることだ。
方針 1: 監視・通知を優先し、適用は人間が行う
apt upgrade の定期実行は自動化しつつ、保留が出たら通知して人間が原因を確認し、対応策を選ぶ。
変化が大きい更新を自動で通さないことで事故を減らす考え方である。
方針 2: セキュリティ更新のみ自動化し、保留は別フローで扱う
定期更新の目的を「脆弱性対応」に絞り、セキュリティ更新は自動で進める。
それ以外の保留は定例メンテナンスで処理する。Debian の定期更新設計（PeriodicUpdates など）と整合しやすい。[10][11]
方針 3: 保留を分類し、自動的にエスカレーションする
保留の種類を分類し、たとえば “特定の重要パッケージが保留になったら即通知”“一定回数連続したら調査タスク化” のように運用する。
放置と即対応の境界を決め、例外を減らす方針である。
運用方針一覧（メリット・デメリット）
| 運用方針 | 狙い | メリット | デメリット |
|---|---|---|---|
| 監視・通知を優先（手動判断） | 安全性を最大化し、意図しない変更を避ける | 事故確率が下がる。判断の透明性が高い | 運用コストが上がる。人が見ないと停滞する |
| セキュリティ更新のみ自動化 | 重要修正の遅延を減らしつつ、変更規模を制御する | 現実的な折衷。自動化の効果が出やすい | 保留問題自体は残るので、別フローが必要 |
| 保留分類＋エスカレーション | 放置してよい保留と危険な保留を分ける | 運用が揺れない。検知・対応が標準化される | 分類ルールの設計が必要。例外が続くとルールが肥大化する |
参考文献
- Unix & Linux Stack Exchange, “What does ‘The following packages have been kept back’ mean”. https://unix.stackexchange.com/questions/38837/what-does-the-following-packages-have-been-kept-back-mean
- Super User, “apt says packages have been kept back, what to do?”. https://superuser.com/questions/1107334/apt-says-packages-have-been-kept-back-what-to-do
- Debian manpages, “apt-mark(8) (unstable)”. https://manpages.debian.org/unstable/apt/apt-mark.8.en.html
- Debian manpages, “apt-mark(8) (stretch)”. https://manpages.debian.org/stretch/apt/apt-mark.8.en.html
- Ask Ubuntu, “The following packages have been kept back: Why and how do I solve it?”. https://askubuntu.com/questions/601/the-following-packages-have-been-kept-back-why-and-how-do-i-solve-it
- Reddit r/debian, “What is the meaning of ‘The following packages have been kept back’?”. https://www.reddit.com/r/debian/comments/13uypwc/what_is_the_meaning_of_the_following_packages/
- Ubuntu Server Docs, “About apt upgrade and phased updates”. https://ubuntu.com/server/docs/explanation/software/about-apt-upgrade-and-phased-updates/
- Super User, “What’s the difference between apt full-upgrade and apt upgrade?”. https://superuser.com/questions/1653079/whats-the-difference-between-apt-full-upgrade-and-apt-upgrade-when-this-site-sa
- Unix & Linux Stack Exchange, “What is the purpose of running apt-get upgrade then full-upgrade?”. https://unix.stackexchange.com/questions/797510/what-is-the-purpose-of-running-apt-get-upgrade-then-full-upgrade-when-upgrad
- Debian Wiki, “PeriodicUpdates”. https://wiki.debian.org/PeriodicUpdates
- Zenn, “Debian サーバの自動セキュリティ更新”. https://zenn.dev/tetr4lab/articles/bbf4e486038da5
- Debian Wiki, “AutomatedUpgrade”. https://wiki.debian.org/AutomatedUpgrade