Как проверить состояние «apt-get upgrade» после потери соединения ssh?


16

Обычно я обновляю установку Ubuntu через ssh-соединение. Иногда это соединение SSH будет потеряно, или я случайно закрою окно терминала.

Можно ли проверить состояние обновления после повторного входа в систему через ssh?

Ответы:


33

Следующие журналы связаны с подходящими обновлениями:

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

Если команда была dist-upgrade, есть дополнительные журналы в:

/var/log/dist-upgrade

К вашему сведению, обычно безопасно просто перезапустить обновление, и apt продолжит работу с того места, на котором оно остановилось, когда процесс остановился из-за отключения. Тем не мение...

GNU Screen Primer:

Когда вы подключаетесь к удаленному серверу и запускаете длительный процесс на переднем плане, лучше всего использовать GNU Screen. Screen предоставляет виртуальный терминал, который продолжает работать, даже если ваше ssh-соединение потеряно.

Установить экран:

sudo apt-get install screen

Запустить экран:

screen

После запуска экрана вы получите приглашение командной строки, как с обычным терминалом. Затем вы можете запустить обновление из внутреннего экрана:

sudo apt-get upgrade

Чтобы понять, как это работает, «отсоедините» экран, нажав Ctrl + a, d . Это вернет вас к неэкранному терминалу. Вы можете увидеть список запущенных экранов с

screen -list

Если у вас работает только один экран, вы можете подключить его с помощью:

screen -raAd

(Это отсоединяет экран в случае, если он подключен в другом месте, и повторно подключает его к терминалу, который вы в данный момент используете.)

Как правило, вы не можете прокручивать «нормально» изнутри экрана без дополнительной настройки. Чтобы прокрутить экран, нажмите Ctrl-Esc, чтобы войти в режим курсора. Затем вы можете прокрутить вниз и вверх с помощью j и k . Нажмите Esc еще раз, чтобы выйти из режима курсора.

В сети доступно гораздо больше ресурсов для дополнительных функций экрана. Это бесценный стандартный инструмент для системного администрирования.

Смотрите также:


2
+1 голос фактически отвечая на вопрос И упоминая экран :)
Nanne

2
Также, screen -x- присоединяйся к рабочему экрану, не отрывая других, делая сеанс экрана «многопользовательским».
SF.

Это полезно, но включает в себя профилактику в дополнение к ответу. Кроме того, указывается правильный журнал для просмотра, но начинающий пользователь может быть не знаком с tail -fопцией command и flag, которая позволит пользователю наблюдать за прогрессом в реальном времени (или видеть, что он потерпел крах) после авторизоваться." Я знаю его старый и принятый, но я думаю, что хвост должен быть добавлен к этому набору инструкций, потому что в отсутствие этой детали, ответ ниже @TheAnonymousBear является более прямым и конкретным. @doublerebel
oemb1905

Часто sudo dpkg --configure -aбудет продолжать подходящую модернизацию, когда это все еще тратится.
danger89

10

В дополнение к ответу двойного повстанца я заметил сегодня альтернативу.

Я лег спать прошлой ночью после начала обновления по 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 запускает один для вас, при условии, что вы забудете :)
Huckle

интересно, это с do-release-upgradeкомандой, определенной для Ubuntu? У меня никогда не было необходимости проверять Debian, который я использую исключительно, потому что я всегда запускаю его вручную, отсоединяюсь и затем возвращаюсь. И, конечно же, мы используем sudo apt dist-upgradeпосле изменения /etc/apt/sources.listвместо.
oemb1905

Я обнаружил, что да, это специфично для Ubuntu, поэтому любые чистые люди Debian, такие как я, которые исправляют poach из AskUbuntu, не должны предполагать, что это произойдет в их системах. Оригинальная тема на эту тему: 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, чтобы увидеть, что, к счастью, это был подпроцесс, который генерировал диалоговое окно сообщения, ожидающее ввода, поэтому я смог просто убить его, не прерывая весь процесс обновления apt.
CivMeierFan

Этот подход игнорирует исследование того, работает ли процесс dpkg в системе после повторной регистрации. Более того, если он работает, то это может быть в худшем случае потенциально вредным или в лучшем случае просто плохой практикой, поскольку dpkg будет заблокирован, /var/dpkg/lockесли он все еще работает. И, тем не менее, он не отвечает на вопрос о том, как «проверить состояние обновления», а вместо этого будет работать только в случае сбоя обновления (и только тогда, когда блокировка не активна). Я бы никому не рекомендовал такой подход. С уважением, oemb1905
oemb1905
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.