¿Cómo verificar el estado de "apt-get upgrade" después de perder la conexión ssh?


16

Por lo general, actualizo mi instalación de Ubuntu a través de una conexión ssh. A veces esta conexión ssh se perdería o accidentalmente cerraría la ventana del terminal.

¿Es posible verificar el estado de la actualización después de un reinicio de sesión ssh en la computadora?

Respuestas:


33

Los siguientes registros están relacionados con las actualizaciones de apt:

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

Si el comando fue dist-upgrade, hay registros adicionales en:

/var/log/dist-upgrade

Para su información, generalmente es seguro volver a ejecutar la actualización y apt continuará donde se detuvo cuando el proceso murió debido a la desconexión. Sin embargo...

Una cartilla de pantalla GNU:

Al ingresar a un servidor remoto e iniciar un proceso de larga duración en primer plano, es una buena práctica usar GNU Screen. Screen proporciona un terminal virtual que continúa ejecutándose incluso si se pierde su conexión ssh.

Instalar pantalla:

sudo apt-get install screen

Ejecutar pantalla:

screen

Después de ejecutar la pantalla, aparecerá un mensaje de línea de comando como con un terminal normal. Luego puede ejecutar la actualización desde la pantalla interior:

sudo apt-get upgrade

Para entender cómo funciona esto, "separe" la pantalla presionando Ctrl + a, d . Esto lo regresará a la terminal que no es de pantalla. Puede ver la lista de pantallas en ejecución con

screen -list

Si solo tiene una pantalla ejecutándose, puede volver a conectarla con:

screen -raAd

(Esto desconecta la pantalla en caso de que esté conectada a otra parte y la vuelve a conectar al terminal que está ejecutando actualmente).

Por lo general, no puede desplazarse 'normalmente' desde la pantalla sin alguna configuración adicional. Para desplazarse dentro de la pantalla, presione Ctrl-Esc para ingresar al modo de cursor. Luego puede desplazarse hacia abajo y hacia arriba con j y k . Presione Esc nuevamente para salir del modo cursor.

Hay muchos más recursos en la red disponibles para funciones de pantalla adicionales. Es una herramienta estándar invaluable para la administración del sistema.

Ver también:


2
+1 para responder la pregunta Y mencionar la pantalla :)
Nanne

2
Además, screen -x- adjunte a la pantalla en ejecución sin separar a los demás, haciendo que la sesión de pantalla sea "multijugador".
SF.

Esto es útil, pero incluye prevención además de la respuesta. Además, se cita el registro correcto para ver, pero un usuario principiante podría no estar familiarizado con el tail -fcomando y la opción de marca, lo que le permitirá observar el progreso en tiempo real (o ver que se bloqueó) al "volver a" iniciar sesión." Sé que es antiguo y aceptado, pero creo que debería agregarse cola a este conjunto de instrucciones, porque al carecer de este detalle, la respuesta a continuación por @TheAnonymousBear es más directa y directa. @doublerebel
oemb1905

A menudo sudo dpkg --configure -acontinuará con la actualización apta, cuando todavía estaba gastando.
peligro89

10

Además de la respuesta de doublerebel, noté una alternativa hoy.

Me fui a la cama anoche después de comenzar una actualización sobre SSH. Estúpidamente olvidé iniciarlo screeny perdí mi sesión de SSH durante la noche.

Estaba a punto de comenzar a investigar rettycuando noté que roothabía comenzado una screensesión.

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

Así que enumeré rootlas pantallas y las adjunto:

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

Y Bam! Estaba de vuelta en el juego.


Pensé que te habías olvidado de iniciar la pantalla. ¿Cómo se ejecutó la pantalla si "olvidó comenzar en la pantalla"?
oemb1905

1
@ oemb1905 Debido a que Ubuntu inicia uno para usted, bajo el supuesto de que lo olvidará :)
Huckle

interesante, ¿es esto con el do-release-upgradecomando específico de ubuntu? Nunca he tenido la necesidad de revisar Debian, que uso exclusivamente, porque siempre lo ejecuto manualmente, lo desconecto y luego vuelvo. Y, por supuesto, usamos sudo apt dist-upgradedespués de cambiar en su /etc/apt/sources.listlugar.
oemb1905

Lo encontré, sí, esto es específico de Ubuntu, por lo que cualquier persona de Debian pura como yo que solucione furtivamente de AskUbuntu no debería asumir que esto sucederá en sus sistemas. Tema original sobre este tema: serverfault.com/questions/387547/…
oemb1905

¿Cómo sabe que tendrá la pantalla instalada?
Nacht - Restablece a Monica el

4

Para ver la salida en tiempo real del apttrabajo en segundo plano , use:

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

Esta es la respuesta correcta: la respuesta anterior solo indica la ubicación de algunos registros útiles y luego cambia a prevención. Esta respuesta muestra al usuario dónde mirar y cómo mirarlo ( tail) después de lo que llamaron un "reinicio de sesión".
oemb1905

0

Tuve exactamente el mismo problema, perdí mi conexión y el proceso dpkg estaba esperando la entrada.

Quizás la próxima vez intente: sudo dpkg --configure -a


1
Cuando intento esto, todo lo que obtengo es"dpkg: error: dpkg frontend is locked by another process"
CivMeierFan

Hice una prueba de contexto para ver que, afortunadamente, era un subproceso que generaba un diálogo de mensaje en espera de entrada, por lo que pude matar eso sin matar todo el proceso de actualización de apt.
CivMeierFan

Este enfoque ignora la investigación sobre si el proceso dpkg todavía se está ejecutando en el sistema al volver a iniciar sesión. Además, si se está ejecutando, esto podría ser potencialmente dañino en el peor de los casos, o simplemente una mala práctica en el mejor de los casos, ya que dpkg tendrá un bloqueo /var/dpkg/locksi aún se está ejecutando. Y a pesar de todo, no responde a la pregunta de cómo "verificar el estado de actualización" y, en cambio, solo funcionará si la actualización falla (y solo entonces si el bloqueo no está activo). No recomendaría este enfoque a nadie. Respetuosamente, oemb1905
oemb1905
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.