UbuntuサーバーをSSH経由で管理していて、apt upgradeの実行中にネットワークが切断されたら。

特にパッケージ更新の途中でSSHが切れると、

• aptはまだ動いているのか
• dpkgが壊れていないか
• もう一度apt upgradeしてよいのか
• ロックファイルを削除してよいのか

と不安になります。

このような場合に最も重要なのは、すぐにaptを再実行しないことです。

まず現在の状態を確認し、必要な場合だけ復旧処理を行います。

この記事では、apt upgrade中に回線やSSHが切れた場合の確認方法、復旧方法、そして今後安全にアップグレードする方法をまとめます。

---

apt upgrade中に回線が切れたら、まず二重実行しない

SSHが切断されたあと再接続できたとしても、すぐに次のようなコマンドを実行するのは避けます。

sudo apt upgrade

元のaptやdpkgがバックグラウンドでまだ動作している可能性があるためです。

apt/dpkgを二重に実行すると、ロックエラーだけでなく、パッケージ管理状態を複雑にしてしまう可能性があります。

基本方針は、

状態確認 → 必要なら復旧 → 正常性確認

です。

---

1. tmuxを使っていた場合はセッションへ戻る

apt upgradeをtmux内で実行していた場合、SSHが切断されても通常は処理が継続しています。

まずセッションを確認します。

tmux ls

例えばapt-upgradeというセッションが残っていれば、次のコマンドで戻ります。

tmux attach -t apt-upgrade

apt upgradeがまだ実行中なら、そのまま完了まで待ちます。

この場合、基本的に復旧作業は必要ありません。

---

2. apt・dpkgが動いているか確認する

tmuxを使っていなかった場合や、処理状態が分からない場合は、まずプロセスを確認します。

ps aux | grep -E '[a]pt|[d]pkg'

aptやdpkgが実際に処理中であれば、原則として終了するまで待ちます。

続いて、dpkgの状態を確認します。

sudo dpkg --audit

さらに依存関係を確認します。

sudo apt-get check

正常と判断できる目安

dpkg --auditで何も表示されない場合は、未設定状態になっているパッケージが基本的に存在しません。

また、

sudo apt-get check

でエラーが出なければ、パッケージの依存関係も正常と判断できます。

特にaptの履歴にアップグレードの「開始」と「完了」が記録されており、

sudo dpkg --audit

も空であれば、基本的には追加の復旧操作は不要です。

---

3. dpkgが中断していた場合の復旧

apt upgradeが途中で停止し、dpkgの設定処理が完了していない場合があります。

まず重要なのは、aptやdpkgのプロセスが動いていないことを確認することです。

ps aux | grep -E '[a]pt|[d]pkg'

実行中の処理がないことを確認してから、次を実行します。

sudo dpkg --configure -a

これは、展開済みだが設定が完了していないパッケージの設定処理を再開します。

続いて依存関係を修復します。

sudo apt-get -f install

パッケージ情報を更新します。

sudo apt-get update

最後に、改めてアップグレードします。

sudo apt-get upgrade

つまり、復旧時の基本的な流れは次のとおりです。

sudo dpkg --configure -a
sudo apt-get -f install
sudo apt-get update
sudo apt-get upgrade

ただし、これらを実行する前に既存のapt/dpkgプロセスが完全に終了していることを確認してください。

---

4. 「Could not get lock」が出た場合

復旧作業中に、

Could not get lock

というエラーが表示されることがあります。

ここでやってはいけないのが、ロックファイルを手動削除することです。

まず次のコマンドで確認します。

ps aux | grep -E '[a]pt|[d]pkg|[u]nattended'

Ubuntuでは、自分で実行したapt以外にもunattended-upgradesなどの自動更新処理が動いている場合があります。

何らかのパッケージ管理処理が動いている場合は、終了するまで待ちます。

完全に終了したことを確認してから、もう一度目的のコマンドを実行します。

ロックファイルを削除してはいけない理由

apt/dpkgのロックは、複数のパッケージ管理処理が同時にデータベースを書き換えることを防ぐために存在します。

そのため、

sudo rm /var/lib/dpkg/lock

などで強制的に削除する方法は原則として避けます。

ロックエラーが出た場合は、

ロックを消すのではなく、ロックを使用しているプロセスを確認する

のが基本です。

---

5. 「パッケージを上書きしています」などの競合エラーが出た場合

アップグレード中に、ファイルの上書きやパッケージ競合に関するエラーが表示される場合があります。

この場合、その場ですぐに--force系オプションを付けるのはおすすめできません。

まずエラー全文を保存します。

sudo apt-get upgrade 2>&1 | tee ~/apt-upgrade-error.log

これにより、画面にエラーを表示しながら、

~/apt-upgrade-error.log

にも記録できます。

その後、どのパッケージとどのファイルが競合しているのかを確認してから対処します。

特に、

• 異なるリポジトリ由来のパッケージ
• 手動インストールしたdebパッケージ
• サードパーティー製リポジトリ
• 古いパッケージの残骸

などがある環境では競合が発生することがあります。

エラー内容を確認せずに強制上書きすると、別のパッケージを壊してしまう可能性があります。

---

6. 復旧後に正常性を確認する

復旧処理が完了したら、まずdpkgを確認します。

sudo dpkg --audit

続いて依存関係を確認します。

sudo apt-get check

どちらも問題なければ、Ubuntuのパッケージ管理状態は基本的に正常です。

---

7. カーネルやsystemd更新後は再起動も検討する

apt upgradeで、

• Linuxカーネル
• libc
• systemd
• その他の基幹ライブラリ

などが更新された場合は、再起動が必要になる場合があります。

対応環境では次のコマンドで確認できます。

needs-restarting -r

ただし、アップグレードが途中で失敗した状態で慌てて再起動するのではなく、

sudo dpkg --audit
sudo apt-get check

などで正常完了を確認してから再起動する方が安全です。

---

今後はtmuxを使ってapt upgradeする

SSH経由でサーバーを管理する場合、apt upgradeのような長時間かかる処理は、通常のSSHセッションで直接実行するよりtmuxを使う方が安全です。

例えば次のように実行します。

tmux new -s apt-upgrade sudo apt upgrade

これでapt-upgradeという名前のtmuxセッション内でapt upgradeが実行されます。

---

tmuxから一時的に抜ける

処理を残したままtmuxから離れる場合は、

Ctrl+B

を押してから、

D

を押します。

つまり、

Ctrl+B → D

です。

これを「デタッチ」と呼びます。

SSHを切断しても、tmux内の処理はそのまま継続します。

---

SSH再接続後にapt upgradeへ戻る

再接続後、まずtmuxセッションを確認します。

tmux ls

apt-upgradeがあれば戻ります。

tmux attach -t apt-upgrade

これで、切断前の画面から引き続き進行状況を確認できます。

---

nohupを使う方法

tmux以外にnohupを使う方法もあります。

例えばrootシェルから実行する場合は、次のようにできます。

sudo -i

その後、

nohup apt-get upgrade -y > /var/log/apt/manual-upgrade.log 2>&1 </dev/null &

ログは次のコマンドで確認できます。

tail -f /var/log/apt/manual-upgrade.log

SSHが切断されても処理そのものは継続します。

ただし、apt upgradeでは設定ファイルの扱いなどについて対話入力を求められる場合があります。

そのため、サーバーの管理作業では、画面の状態をそのまま復元できるtmuxの方が扱いやすいでしょう。

---

tmuxとnohupのどちらを使うべきか

通常のUbuntuサーバー管理であれば、基本的にはtmuxがおすすめです。

方法	SSH切断後も継続	画面へ戻れる	ログ確認	apt upgradeとの相性
通常のSSH実行	状況による	×	△	△
tmux	○	○	○	◎
nohup	○	×	○	○

nohupはバックグラウンドで完全自動処理したい場合には便利ですが、apt upgradeのように途中経過を確認したい管理作業ではtmuxの方が使いやすいです。

---

apt upgrade中に切断された場合の確認手順まとめ

SSHやネットワークが切断されたら、次の順番で確認すると安全です。

1. tmuxを使っていた場合

tmux ls
tmux attach -t apt-upgrade

処理中なら、そのまま完了まで待ちます。

2. apt/dpkgを確認

ps aux | grep -E '[a]pt|[d]pkg'

3. dpkgを確認

sudo dpkg --audit

4. 依存関係を確認

sudo apt-get check

5. dpkgが中断している場合

apt/dpkgが動いていないことを確認してから、

sudo dpkg --configure -a
sudo apt-get -f install
sudo apt-get update
sudo apt-get upgrade

を実行します。

6. ロックエラーの場合

ps aux | grep -E '[a]pt|[d]pkg|[u]nattended'

で使用中のプロセスを確認し、ロックファイルは手動削除しません。

---

まとめ

Ubuntuでapt upgrade実行中にSSHやインターネット接続が切断されても、すぐにシステムが壊れたと判断する必要はありません。

重要なのは、焦ってもう一度aptを実行しないことです。

まず、

ps aux | grep -E '[a]pt|[d]pkg'
sudo dpkg --audit
sudo apt-get check

で状態を確認します。

aptの履歴に正常な「開始・完了」が残っており、

sudo dpkg --audit

にも何も表示されず、

sudo apt-get check

にもエラーがなければ、基本的に追加の復旧操作は必要ありません。

今後SSH経由で、

sudo apt upgrade

のような長時間処理を行う場合は、

tmux new -s apt-upgrade sudo apt upgrade

のようにtmux内で実行しておくと安心です。

ネットワークが途中で切れても、

tmux attach -t apt-upgrade

で元の処理へ戻れるため、Ubuntuサーバーのリモート管理では非常に有効な対策です。