Fabric: Reinicio roto en hosts Ubuntu 16.04

Es exactamente lo mismo con ejecutar ('reiniciar')

Lo mismo ocurre con un run manual no es sorprendente; claramente, algo cambió con respecto al manejo de reinicio de Ubuntu, conexiones SSH, etc.

No se le ocurre nada obvio, pero reboot() (Fab's, no Linux) es bastante básico: simplemente llama a sudo('reboot') y modifica temporalmente la configuración general de reconexión de Fabric para que pueda manejar la reconexión después de una secuencia de reinicio no trivial (frente al predeterminado, que se daría por vencido bastante rápido).

Consulte https://github.com/fabric/fabric/blob/c0224a52df59821f21a8c0bd47ce15e42c2046a4/fabric/operations.py#L1244 ; es posible que desee intentar modificar eso.

También intente habilitar el registro de Paramiko (consulte la parte inferior de nuestra página de solución de problemas: http://www.fabfile.org/troubleshooting.html), ya que podría dar una pista.

En realidad, pensándolo bien, parece que el reboot Ubuntu de alguna manera nunca sale ni envía un código de salida a los controladores de ejecución de Fabric ( run / sudo ), ya que observa que sudo es lo que se enoja cuando machacas Enter después de esperar.

Si observa el código reboot() , espera que la llamada sudo('reboot') salga eventualmente, de modo que pueda A) esperar un poco y B) iniciar la reconexión.

El hecho de que, al final de Fabric, la ejecución simplemente se cuelgue dentro del sudo significa que algo de forma remota está violando esa expectativa. Un poco extraño. _Tal vez_ un error en Fabric en sí, pero se siente más como un mal comportamiento en el extremo remoto. (PD: ¿en qué versiones de tela está viendo esto?)

Pensamiento imprevisto: tal vez podríamos establecer timeout= en sudo , luego except TimeoutException: pass alrededor. Esto aseguraría que incluso en esta (extraña) situación, intentamos de forma predeterminada una reconexión.

El único inconveniente sería el caso en el que reboot realmente se cuelga y el sistema no se reinicia realmente, pero no es como si hiciéramos las cosas _peor_ para ese caso con el cambio anterior: el bloqueo infinito simplemente ocurriría el bucle de conexión en lugar de dentro de sudo .

Otro comportamiento realmente extraño y cambiado en Ubuntu 16.04 es el siguiente. Cuando ejecuto poweroff en una sesión ssh, la máquina se apaga, ¡pero las sesiones SSH se cuelgan! No hay forma de Ctrl + C, Ctrl + D, ni nada. Todo lo que puedo hacer es esperar un _lot_ y luego ssh aborta con:
packet_write_wait: Connection to 192.168.56.11: Broken pipe

Realmente no estoy en los bolsillos profundos del manejo de la conexión SSH, pero este podría ser exactamente el mismo problema que con el reinicio.

Me acabo de encontrar con un reinicio roto (Ubuntu 16.04 actualizado en AWS, Fabric == 1.12.0) pero de una manera diferente. Para mí solo arroja:

Fatal error: sudo() received nonzero return code -1 while executing!

Requested: reboot
Executed: sudo -S -p 'sudo password:'  /bin/bash -l -c "reboot"

Ejecutar sudo reboot en la terminal a mano funciona (el host se reinicia).

Vale la pena señalar:

$ readlink /sbin/reboot 
/bin/systemctl
$ readlink /sbin/shutdown
/bin/systemctl

Y otra cosa extraña. Cambié el código de reinicio para usar aws-cli y después de su llamada (que toma ~ 1 segundo, parece que es asíncrono) ejecuto sudo('add-apt-repository --yes ppa:nginx/stable') . Siempre ha funcionado, pero ahora, después de reiniciar, también devolvió -1:

sudo: add-apt-repository --yes ppa:nginx/stable

Fatal error: sudo() received nonzero return code -1 while executing!

Requested: add-apt-repository --yes ppa:nginx/stable
Executed: sudo -S -p 'sudo password:'  /bin/bash -l -c "add-apt-repository --yes ppa:nginx/stable"

Luego intenté hacer una tela para volver a conectar agregando fabric.network.disconnect_all() . Resultó en solicitar una contraseña (¿por qué?):

[...] sudo: add-apt-repository --yes ppa:nginx/stable
[...] Login password for 'ubuntu': 

Y comenzó a funcionar solo después de que agregué, por ejemplo, time.sleep(60 * 3) después de reiniciar. Lo que obviamente es una curita deficiente, y ahora me desconcierta cómo manejar correctamente el problema de la contraseña. Parece que está relacionado con este problema.

El problema parece ser que "reiniciar" ahora es a veces "demasiado rápido", antes de que el estado del comando vuelva a pasar por la conexión ssh.

(Sugerencia: si se encuentra en una conexión ssh congelada como resultado: escriba \n~. también conocido como enter, tilde, punto. Ese es el carácter de escape ssh predeterminado, luego el comando de desconexión para ssh. Si solo intenta ctrl- c o ctrl-d, ssh intenta pasar eso al proceso que se ejecuta en el otro lado).

Una solución es usar shutdown -r +1 , que programará el reinicio para el próximo minuto, y luego esperará un minuto para que comience y luego comenzará a intentar volver a conectarse. Es cierto que esperar un minuto no es genial.

Algo hacky para probar: shutdown -r +0 debería ser equivalente a reboot , pero en mis pruebas limitadas de Ubuntu-16.04 ejecutándose en VirtualBox, tiende a dar una fracción de segundo más, mostrando el siguiente indicador de shell justo antes de desconectar una sesión ssh manual.

este es probablemente un duplicado de # 1444

Si el demonio init se cambia a upstart, el reinicio funciona como se esperaba. Parece que systemd está matando sshd inmediatamente.

Hubo un error en el paquete de systemd de Debian / Ubuntu que, al cerrarse, mató el servicio de red antes que el SSH, por lo que todo se bloqueó.
Se corrigió en el último lanzamiento puntual. No sé sobre el estado del paquete de Ubuntu.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751636

Informó el error para Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1645002

También tuve problemas con el uso de reboot () en algunos de mis scripts. Descubrí que cuando me conectaba con una contraseña, el reinicio funcionaba correctamente, pero cuando usaba la autenticación de archivo de claves, la conexión se colgaba (y se reiniciaba).

El error de ubuntu https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1645002 está marcado como corregido en 16.10, pero aún no en 16.04, y no está claro cuándo será.

El comportamiento actual para mí es que paramiko / fabric detecta instantáneamente que la conexión ssh se cerró, pero es antes de que paramiko / fabric vea que el comando de reinicio se ha completado. Al menos no se cuelga indefinidamente como en el informe original.

Fatal error: sudo() received nonzero return code -1 while executing!
...
Aborting.

Plain reboot() hizo eso de manera consistente por mí en un puñado de pruebas contra AWS EC2 y una máquina virtual virtualbox local. (Siempre usé la autenticación de archivo de claves).

Encontré una solución breve y elegante, como sugerí sin tantos detalles arriba:

reboot(command="shutdown -r +0")

Eso funcionó como se esperaba para mí (en mi puñado de pruebas contra AWS EC2 y VM virtualbox local, todas ejecutando ubuntu 16.04 actualizado). Tenga en cuenta que "shutdown -r now" se comportó como "reiniciar" y no pareció funcionar.

Eché un vistazo rápido a las páginas de manual de freebsd y openbsd, y parece que tienen un comando de apagado que admite esos parámetros. Sospecho que el comando "shutdown -r +0" funcionaría para prácticamente cualquier sistema Unix en el que funcionó "reboot". Por lo tanto, podría considerarse para cambiar el comando predeterminado o actualizar la documentación. (Pero me interesaría ver primero un informe de una prueba en un sistema BSD).

shutdown -r +0 no es suficiente para nosotros. Dado que el reinicio no acepta un tiempo de espera manual, incluso he intentado algo como:

try:
    sudo("shutdown -r +0", timeout=300)
except NetworkError:
    pass
# in case the sudo times out during reboot
sleep(15)

A pesar de todo este movimiento de la mano, el siguiente comando se cuelga indefinidamente. ¿Es posible que el grupo de conexiones esté reteniendo (y usando) la conexión muerta? Si es así, ¿hay alguna solución? ¿Puedo reducir temporalmente el tiempo de espera del nivel de conexión?

De hecho, debe reemplazar la conexión existente, como lo hace reboot() :

https://github.com/fabric/fabric/blob/1.13.2/fabric/operations.py#L1289 -L1294

Disculpas por revivir un problema anterior, también puedo confirmar que este problema ocurre al intentar reiniciar un contenedor LXC. La sugerencia de @ploxiln de usar command="shutdown -r +0" funcionó para nosotros.

Confirmando este error en una nueva instalación de FreeBSD 11.1 con bash instalado:

reboot(wait=1) resulta en:

Fatal error: sudo() received nonzero return code -1 while executing!

Requested: reboot
Executed: sudo -S -p 'sudo password:'  /usr/local/bin/bash -l -c "reboot"

Aborting.
Traceback (most recent call last):
…
    raise env.abort_exception(msg)
hosts.FabricException: sudo() received nonzero return code -1 while executing!

Terminé necesitando esto para que las cosas funcionen después de leer los comentarios de @ ambsw-technology y @ploxiln . Estoy corriendo contra un servidor ubuntu 16.04 LTS (desde un cliente de Windows).

sudo('shutdown -r +0')
time.sleep(30)
fabric.state.connections.connect(env.host_string)

Para su información, todavía veo esto contra los servidores 18.04.2 LTS.

¿Alguna solución para esto? también tengo problemas con 16.04