SSH接続が失われた後、「apt-get upgrade」ステータスを確認する方法は?


16

通常、SSH接続を介してUbuntuインストールをアップグレードします。このssh接続が失われたり、誤ってターミナルウィンドウを閉じたりすることがありました。

sshがコンピューターに再ログインした後、アップグレードステータスを確認することは可能ですか?

回答:


33

次のログは、aptアップグレードに関連しています。

/var/log/apt/history.log
/var/log/apt/term.log
/var/log/dpkg.log

コマンドがの場合、dist-upgrade追加のログがあります:

/var/log/dist-upgrade

参考までに、通常はアップグレードを再実行するだけで安全であり、切断によりプロセスが停止したときに中断したところからaptが続行します。しかしながら...

GNU Screen Primer:

リモートサーバーにsshし、フォアグラウンドで長時間実行されるプロセスを開始する場合、GNU Screenを使用するのがベストプラクティスです。Screenは、ssh接続が失われた場合でも実行を継続する仮想端末を提供します。

インストール画面:

sudo apt-get install screen

実行画面:

screen

画面を実行すると、通常の端末と同様にコマンドラインプロンプトが表示されます。その後、内部画面からアップグレードを実行できます。

sudo apt-get upgrade

これがどのように機能するかを理解するには、Ctrl + a、dを押して画面を「切り離し」ます。これにより、非スクリーン端末に戻ります。実行中の画面のリストを表示するには

screen -list

実行中の画面が1つしかない場合は、次の方法で再接続できます。

screen -raAd

(これは、他の場所に接続されている場合に画面を切り離し、現在実行中の端末に再接続します。)

通常、追加のセットアップを行わないと、画面内から「通常」スクロールできません。画面内をスクロールするには、Ctrl-Esc押してカーソルモードに入ります。その後、jkで上下にスクロールできます。押して、Escキーをもう一度カーソルモードを終了します。

追加の画面機能に使用できるネット上のリソースは他にもたくさんあります。これは、システム管理のための非常に貴重な標準ツールです。

こちらもご覧ください:


2
実際に質問に答え、画面について言及する+1票:)
ナネ

2
また、screen -x-他を切り離すことなく実行中の画面に接続し、画面セッションを「マルチプレイヤー」にします。
SF。

これは役立ちますが、答えに加えて予防が含まれます。さらに、見るべき正しいログが引用されますが、初心者ユーザーはtail -fコマンドとフラグのオプションに慣れていない可能性があります。これにより、ユーザーは「再-ログインする。" 私はその古いものと受け入れられていることを知っていますが、この詳細に欠けているため、@ TheAnonymousBearによる以下の答えはより直接的で要点であるため、この命令セットにテールを追加する必要があると思います。@doublerebel
oemb1905

10

doublerebelの答えに加えて、私は今日代替案に気付きました。

昨夜、SSH経由のアップグレードを開始した後、就寝しました。愚かにもそれを開始するのを忘れましたscreen、一晩でSSHセッションを失いました。

セッションを開始したrettyことに気づいたとき、私はちょうど研究を始めようとしrootていましたscreen

me@GAMMA:~$ ps aux | grep -E 'release|upgrade|apt'
root      6208  0.0  0.0  29140  1628 ?        Ss   01:57   0:05 SCREEN -e \0\0 -L -c screenrc -S ubuntu-release-upgrade-screen-window /tmp/ubuntu-release-upgrader-1h6_g4/raring --mode=server --frontend=DistUpgradeViewText
root      6209  0.2  5.6 287428 93144 pts/2    Ss+  01:57   3:13 /usr/bin/python /tmp/ubuntu-release-upgrader-1h6_g4/raring --mode=server --frontend=DistUpgradeViewText
root      6239  0.0  0.0  50052  1184 ?        Ss   01:58   0:00 /usr/sbin/sshd -o PidFile=/var/run/release-upgrader-sshd.pid -p 1022
root      7306  0.0  4.6 287432 77284 pts/2    S+   02:43   0:08 /usr/bin/python /tmp/ubuntu-release-upgrader-1h6_g4/raring --mode=server --frontend=DistUpgradeViewText
me       26829  0.0  0.0   9440   956 pts/5    S+   22:18   0:00 grep --color=auto -E release|upgrade|apt

rootの画面をリストして添付しました:

me@GAMMA:~$ sudo screen -list
There is a screen on:
        6208.ubuntu-release-upgrade-screen-window       (12/11/2013 01:57:58 AM)        (Detached)
1 Socket in /var/run/screen/S-root.
me@GAMMA:~$ sudo screen -x -r

そしてバム!私はゲームに戻った。


画面を起動するのを忘れたと思った。「画面で起動するのを忘れた」場合の画面の実行方法
oemb1905

1
@ oemb1905 Ubuntuが自動的に起動するため、忘れるという前提の下で:)
ハックル

興味深いのは、do-release-upgradeubuntu固有のコマンドですか?常に手動で実行し、切り離してから戻ってくるので、Debianを独占的に使用する必要はありませんでした。そして、もちろん、代わりsudo apt dist-upgradeに変更してから使用し/etc/apt/sources.listます。
oemb1905

はい、これはUbuntu固有であるため、AskUbuntuからの密猟修正がシステムで発生すると想定すべきではない、私のような純粋なDebianの人々はそうです。このトピックに関するオリジナルスレッド: serverfault.com/questions/387547/...
oemb1905

画面がインストールされることをどのように確認しますか?
Nacht-モニカの復活

4

バックグラウンドaptジョブからのリアルタイム出力を表示するには、次を使用します。

sudo tail -f /var/log/apt/term.log

これが正しい答えです。上記の答えは、いくつかの有用なログの場所を示してから、予防に切り替えます。この答えは、ユーザーがtail「再ログイン」と呼んだものの後に、どこで見るべきか、どのように見るか()を示しています。
oemb1905

0

まったく同じ問題があり、接続が失われ、dpkgプロセスが入力を待っていました。

たぶん次回は試してみてください: sudo dpkg --configure -a


1
私がこれを試すとき、私が得るすべては"dpkg: error: dpkg frontend is locked by another process"
-CivMeierFan

ありがたいことに、入力を待機しているメッセージダイアログを生成するサブプロセスであることがわかったので、コンテキストgrepを実行しました。
-CivMeierFan

このアプローチでは、再ログイン時にdpkgプロセスがシステムでまだ実行されているかどうかの調査は無視されます。さらに、実行中の場合、dpkg /var/dpkg/lockはまだ実行中の場合にロックされるため、これは最悪の場合は潜在的に有害であるか、せいぜい悪いプラクティスにすぎない可能性があります。とにかく、「アップグレードステータスを確認する方法」の質問には答えず、代わりに、アップグレードがクラッシュした場合(そしてロックがアクティブでない場合のみ)に機能します。このアプローチは誰にもお勧めしません。敬具、oemb1905
oemb1905
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.