Як перевірити стан "apt-get upgrade" після втрати ssh-зв’язку?


16

Зазвичай я оновлюю свою установку Ubuntu через ssh-з'єднання. Іноді це ssh-з'єднання буде втрачено або я випадково закрию вікно терміналу.

Чи можна перевірити стан оновлення після повторного входу в комп’ютер ssh?

Відповіді:


34

Наступні журнали пов’язані з влучними оновленнями:

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

Якщо команда була dist-upgrade, у додатку є додаткові журнали:

/var/log/dist-upgrade

FYI, зазвичай безпечно просто повторно запустити оновлення, і вкладення триватиме там, де воно припинилося, коли процес помер через відключення. Однак ...

GNU Screen Primer:

Коли ssh'ing на віддалений сервер і запускає тривалий процес на передньому плані, найкращою практикою є використання 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, щоб вийти з режиму курсору.

У мережі є набагато більше ресурсів, доступних для додаткових функцій екрану. Це неоціненний стандартний інструмент для адміністрування системи.

Дивись також:


2
+1 голос насправді відповідав на питання І згадуючи екран :)
— Nanne

3
Крім того, screen -x- приєднати до запущеного екрану, не відриваючи інших, зробивши сеанс екрану "багатокористувацьким".
— СФ.

Це корисно, але включає відповідь на додаток до відповіді. Крім того, правильний журнал, який потрібно переглянути, цитується, але користувач-початківець може не бути знайомий з параметром tail -fкоманд та прапорців, що дозволить користувачеві спостерігати за прогресом у режимі реального часу (або бачити, що він вийшов з ладу) після " вхід. " Я знаю його давнє і прийняте, але я думаю, що хвостик слід додати до цього набору інструкцій, оскільки, якщо не вистачає цієї деталі, відповідь, подана нижче від @TheAnonymousBear, є більш прямою і суттєвою. @doublerebel
— oemb1905

Часто sudo dpkg --configure -aпродовжуватимуть вдосконалене оновлення, коли це ще витрачалось.
— небезпека89

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-upgradeкомандою, характерною для ubuntu? У мене ніколи не було необхідності перевіряти Debian, яким я користуюся виключно, тому що я завжди запускаю його вручну, відключаю, а потім повертаюся. І, звичайно, ми використовуємо sudo apt dist-upgradeпісля зміни /etc/apt/sources.listзамість цього.
— oemb1905

Я знайшов це, так, це специфічно для Ubuntu, тому будь-які чисті люди з Debian, як я, які виправляють виправлення з AskUbuntu, не повинні вважати, що це станеться в їхніх системах. Оригінальна тема на цю тему: serverfault.com/questions/387547/…
— oemb1905

Звідки це відомо, що у вас буде встановлений екран?
— Нахт -

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

Я зробив контекстну помилку, щоб побачити, що, на щастя, це був підпроцес, який генерував діалог повідомлень, що чекає на введення, тому я зміг просто вбити це, не вбиваючи весь процес влучного оновлення.
— CivMeierFan

Цей підхід ігнорує дослідження того, чи процес dpkg все ще працює в системі після повторного входу. Більше того, якщо він працює, то це може бути в гіршому випадку потенційно шкідливим або в кращому випадку поганою практикою, оскільки dpkg буде заблокувати його, /var/dpkg/lockякщо він все ще працює. І незалежно, він не відповідає на питання про те, як "перевірити стан оновлення", а натомість буде працювати лише в тому випадку, коли оновлення вийшло з ладу (і лише тоді, якщо блокування не активне). Я б не рекомендував такого підходу нікому. З повагою, oemb1905
— oemb1905
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.