Как проверить & ldquo; apt-get upgrade & rdquo; статус после потери соединения ssh?
Обычно я обновляю установку Ubuntu через ssh-соединение. Иногда это соединение SSH будет потеряно, или я случайно закрою окно терминала.
Можно ли проверить состояние обновления после повторного входа в систему через ssh?
5 ответов
Чтобы увидеть вывод в реальном времени из фонового задания apt, используйте:
sudo tail -f /var/log/apt/term.log
В дополнение к ответу двойного повстанца, я заметил сегодня альтернативу.
Я пошел спать прошлой ночью после начала обновления по 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
И Бэм! Я вернулся в игру.
Следующие журналы связаны с подходящими обновлениями:
/var/log/apt/history.log
/var/log/apt/term.log
/var/log/dpkg.log
Если команда была dist-upgrade, есть дополнительные журналы в:
/var/log/dist-upgrade
FYI, обычно это безопасно просто повторно запустить обновление и apt продолжит с того места, на котором он остановился, когда процесс остановился из-за отключения. Однако ...
Учебник по экрану GNU:
При подключении к удаленному серверу и запуске долгого процесса на переднем плане рекомендуется использовать экран GNU. Screen предоставляет виртуальный терминал, который продолжает работать, даже если ваше ssh-соединение потеряно.
Экран установки:
sudo apt-get install screen
Рабочий экран:
screen
После рабочего экрана вы получите приглашение командной строки, как с обычным терминалом. Затем вы можете запустить обновление из внутреннего экрана:
sudo apt-get upgrade
Чтобы понять, как это работает, «отсоедините» экран, нажав Ctrl + a, d . Это вернет вас к неэкранному терминалу. Вы можете увидеть список запущенных экранов с помощью
screen -list
Если у вас работает только один экран, вы можете подключить его с помощью:
screen -raAd
(Это отсоединяет экран, если он подключен в другом месте и подключите его к терминалу, на котором вы сейчас работаете.)
Обычно вы не можете прокручивать «нормально» изнутри экрана без какой-либо дополнительной настройки. Для прокрутки на экране нажмите Ctrl-Esc , чтобы войти в режим курсора. Затем вы можете прокрутить вниз и вверх с помощью j и k . Нажмите Esc еще раз, чтобы выйти из режима курсора.
В сети доступно гораздо больше ресурсов для дополнительных функций экрана. Это бесценный стандартный инструмент для системного администрирования.
См. Также:
У меня была точно такая же проблема, я потерял связь, и процесс dpkg ждал ввода.
Может быть, в следующий раз попробуйте: sudo dpkg --configure -a
TL;DR: после потери ssh-соединения у вас может появиться недоступное диалоговое окно консоли, блокирующее продолжение обновления. Убейте процесс whiptail, чтобы он мог продолжить работу.
У меня была похожая проблема, и хотя некоторые ответы были полезными, они не помогли мне решить мою проблему. Но между ответом @Huckle и вторым комментарием @CivMeierFan к ответу @Sebastian Faujour я нашел свой путь вперед.
«ps aux | grep -E 'release|upgrade|apt'» показал процесс whiptail (также показанный с «/var/log/apt/term.log», но в этом случае он только что выдал непригодное консольное приглашение. Полезно понять, почему обновление было заблокировано, но бесполезно для решения проблемы).
Уничтожение процесса whiptail позволило продолжить обновление.