¿Por qué se cuelga systemd durante el reinicio?


13

1 de cada 10 veces, systemd se bloquea durante el reinicio. No entiendo el motivo. ¿Qué / dónde debo mirar para solucionar el problema? Estoy usando systemd v196 y no puedo actualizarlo a la versión> = 198 porque este último requiere un kernel reciente (con soporte para cgroups), que no puede actualizarse según los requisitos del cliente. Me pregunto si hay una forma razonable de descubrir la razón de este comportamiento y hacer que el sistema reinicie el sistema incondicionalmente.

Tenga en cuenta que este enlace no ayuda: http://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1

Como puedes leer allí:

El apagado nunca termina

Si el reinicio o el apagado normales nunca terminan, incluso después de esperar unos minutos, el método anterior para crear el registro de apagado no ayudará y el registro debe obtenerse utilizando otros métodos. Dos opciones que son útiles para depurar problemas de arranque se pueden usar también para problemas de apagado:

use a serial console
use a debug shell - not only is it available from early boot, it also stays active until late shutdown.

Estoy usando la consola serie y, por alguna razón, incluso puedo iniciar sesión, ya que la interfaz eth está activada o se ha activado (después de una desconexión durante los pasos de reinicio).

No veo el motivo.

# cat /etc/systemd/system/
basic.target.wants/                          getty.target.wants/                          multi-user.target.wants/                     sysinit.target.wants/                        
dbus-org.freedesktop.NetworkManager.service  local-fs-pre.target.wants/                   sockets.target.wants/                        syslog.service                               
display-manager.service                      local-fs.target.wants/                       swap.target

Tenga en cuenta el swap.target. Está ahí, pero no usamos particiones de intercambio en absoluto. Traté de enmascarar el intercambio, pero el problema de colgar continúa. La última línea en la consola es:

[OK] Stopped target shutdown.

EDITAR: Como dije, puedo volver a iniciar sesión a través de ssh sobre eth.

Ahora te mostraré dos registros. El primer registro ocurre cuando se reinicia el reinicio / shutdwon, mientras que el segundo registro es cuando el reinicio se realiza correctamente:

Cuelgue el caso, la salida siempre es así (registro completo):

[  OK  ] Stopped Network Time Service (one-shot ntpdate mode).
         Stopping Modem and VPN connections autoconnect...
         Stopping Login Service...
         Stopping LSB: Avahi mDNS/DNS-SD Daemon...
[  OK  ] Stopped Monitoring free system resources.
[  OK  ] Stopped Monitoring dropbear socket.
[  OK  ] Stopped Login Service.
[  OK  ] Stopped Modem and VPN c[  OK  ] Stopped Getty on tty1.
[  OK  ] Stopped Serial Getty on ttyO0.
[  OK  ] Unmounted /var/lib/opkg.
[  OK  ] Stopped Network Manager.
[  OK  ] Stopped LSB: Avahi mDNS/DNS-SD Daemon.
         Stopping D-Bus System Message Bus...
[  OK  ] Stopped target Remote File Systems.
[  OK  ] Stopped Suspend manager.
         Stopping X Server...
[  OK  ] Stopped X Server.
         Stopping System Logging Service...
[  OK  ] Stopped System Logging Service.
[   77.580000] g_ether gadget: using random self ethernet address
[   77.580000] g_ether gadget: using random host ethernet address
[   77.590000] usb0: MAC 6e:0d:de:b0:33:4f
[   77.590000] usb0: HOST MAC 62:7a:81:02:f3:ff
[   77.600000] g_ether gadget: Ethernet Gadget, version: Memorial Day 2008
[   77.600000] g_ether gadget: g_ether ready
[   77.610000] musb-hdrc musb-hdrc.0: MUSB HDRC host driver
[   77.610000] musb-hdrc musb-hdrc.0: new USB bus registered, assigned bus number 2
[   77.620000] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002
[   77.630000] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[   77.640000] usb usb2: Product: MUSB HDRC host driver
[   77.640000] usb usb2: Manufacturer: Linux 2.6.37 musb-hcd
[   77.650000] usb usb2: SerialNumber: musb-hdrc.0
[   77.650000] hub 2-0:1.0: USB hub found
[   77.660000] hub 2-0:1.0: 1 port detected
[   77.690000] ADDRCONF(NETDEV_UP): usb0: link is not ready
[  OK  ] Stopped target Reboot.
[  OK  ] Stopped Reboot.
[  OK  ] Stopped target Unmount All Filesystems.
[  OK  ] Stopped target Shutdown.
[   78.330000] <46>systemd-journald[328]: Received SIGUSR1
<hang>

Reinicio normal:

         Unmounting /var/lib/opkg...
[  OK  ] Stopped target Network.
         Stopping SSH Per-Connection Server...
[  OK  ] Stopped target Graphical Interface.
[  OK  ] Stopped target Multi-User.
         Stopping Monitoring free system resources...
         Stopping Monitoring dropbear socket...
         Stopping Network Time Service (one-shot ntpdate mode)...
[  OK  ] Stopped Network Time Service (one-shot ntpdate mode).
         Stopping Modem and VPN connections autoconnect...
         Stopping Login Service...
         Stopping LSB: Avahi mDNS/DNS-SD Daemon...
[  OK  ] Stopped Monitoring free system resources.
[  OK  ] Stopped Monitoring dropbear socket.
[  OK  ] Stopped Login Service.
[  OK  ] Unmounted /var/lib/opkg.
         Stopping Network Manager...
[  OK  ] Stopped Getty on tty1.
[  OK  ] Stopped Network Manager.
[  OK  ] Stopped Serial Getty on ttyO0.
[  OK  ] Stopped Suspend manager.
[  OK  ] Stopped LSB: Avahi mDNS/DNS-SD Daemon.
         Stopping D-Bus System Message Bus...
         Stopping X Server...
         Stopping Permit User Sessions...
[  OK  ] Stopped Permit User Sessions.
[  OK  ] Stopped target Remote File Systems.
[  OK  ] Stopped X Server.
[  OK  ] Stopped D-Bus System Message Bus.
         Stopping System Logging Service...
[  OK  ] Stopped System Logging Service.
[  OK  ] Stopped target Basic System.
[  OK  ] Stopped target Sockets.
[  OK  ] Closed dropbear.socket.
[  OK  ] Closed D-Bus System Message Bus Socket.
[  OK  ] Stopped target System Initialization.
         Stopping Import configuration from SD card...
[  OK  ] Stopped Import configuration from SD card.
         Stopping Load Kernel Modules...
         Stopping Apply Kernel Variables...
[  OK  ] Stopped Apply Kernel Variables.
[  OK  ] Stopped target Local File Systems.
         Unmounting /var...
         Unmounting /tmp...
[  OK  ] Closed Syslog Socket.
[  OK  ] Failed unmounting /var.
[  OK  ] Unmounted /tmp.
[  OK  ] Stopped Load Kernel Modules.
[  OK  ] Reached target Unmount All Filesystems.
[  OK  ] Stopped target Local File Systems (Pre).
         Stopping Remount Root and Kernel File Systems...
[  OK  ] Stopped Remount Root and Kernel File Systems.
[  OK  ] Reached target Shutdown.
[   52.340000] omap_wdt: Unexpected close, not stopping!
Sending SIGTERM to remaining processes...
[   52.490000] <46>systemd-journald[335]: Received SIGTERM
Sending SIGKILL to remaining processes...
Unmounting file systems.
Unmounting /sys/fs/fuse/connections.
Unmounting /var.
All filesystems unmounted.
Deactivating swaps.
All swaps deactivated.

ACTUALIZAR:

Después de algunas investigaciones y depuración, descubrí la razón de la interrupción del cierre, aunque todavía no puedo resolverlo. Lo que sucede es que, por alguna razón, uno de los servicios personalizados se inicia antes de que se complete el apagado, lo que hace que el procedimiento de apagado se bloquee. Ese es un caso de colgar. Otro tipo de bloqueo es cuando el apagado no se interrumpe pero se detiene en algún momento. Por estas razones, antes de resolver todos los conflictos y otros posibles bloqueos uno a la vez, quiero activar incondicionalmente el watchdog de hardware. Para hacer esto a través de systemd, he habilitado y probado, por separado o en conjunto, RuntimeWatchdogSec y ShutdownWatchdogSec. Lamentablemente, no ayudaron. Al mirar el código fuente,

Estoy atascado. Lo que le pido es que encuentre una manera de: 1. Habilitar el perro guardián incondicionalmente, al menos desde el punto donde comienza el apagado 2. Detectar y resolver todos los conflictos de una manera fácil.

Se prefiere la primera solución.


¿Está en el camino que cuelga? ¿Puedes compartir con nosotros qué servicios están habilitados en el sistema? ¿Algún encargo? ¿Cómo llegaste a la conclusión de que systemd se cuelga?
MattBianco

@MattBianco Edité la pregunta. Hay mas informacion.
Martin

¿Por qué no veo líneas iguales entre el primer y el segundo registro? Podría ofrecer más ayuda si pudiera ver dónde comienzan a diferir.
BenjiWiebe

@BenjiWiebe tienes razón. Editaré la pregunta nuevamente
Martin

intente usar journalctl como root y busque tiempos de espera, fallas y fallas de dependencia en el diario systemd.
harrymc

Respuestas:


5

Me atrevo a sugerir una solución: intente agregar

  Before=basic.target

a /usr/lib/systemd/system/dbus.service.

Me sorprende una rareza, en sus registros, que me recuerda un accidente del que he leído hace algún tiempo, en los foros de Arch Linux : este sistema se colgaría al reiniciar. La solución se ofreció como se indicó anteriormente, debido a que el bloqueo sería causado por algún servicio que intentara hablar con d-bus después de que se detuviera:

Por lo tanto, al ordenarlo antes de basic.target, no solo comienza antes de que se alcance el objetivo básico, sino que también se asegura de que permanezca hasta después de que se derriba basic.target durante el apagado.

En su registro no saludable , vemos de hecho que el sistema básico no se detiene, mientras que se detiene correctamente en el registro saludable .

Si esto no funciona, y considerando que no puede actualizar, ¿ha considerado una rebaja?


1
Gracias, probaré tu solución. He considerado un reemplazo para el viejo SysV, ya que systemd parece estar fallado por diseño.
Martin

Obtengo esto de systemd en el arranque después de haber aplicado ese cambio: se encontró el ciclo de pedido, omito el bus de mensajes del sistema D-Bus. ¿Alguna idea?
Martin

@ Martin 1: ¿tiene / y / usr en particiones separadas? 2) ¿tienes muchas cosas en /etc/init.d? ¿O en /etc/rc.d?
MariusMatutiae

1
esto funciona muy bien en Ubuntu 16.04, el archivo se encontraba en /usr/lib/systemd/user/dbus.servicevirtud de [Unit]la sección
Anwar

3

shutdown.targetentra en conflicto con todas las demás unidades de forma predeterminada, para detenerlas automáticamente cuando comienza el proceso de apagado. Esto también funciona a la inversa: si se inicia otra unidad, se shutdown.targetdetiene. Entonces, el problema es que algo hace que algo se inicie durante el apagado, lo que anula el proceso de apagado.

Esto debería haberse solucionado en systemd v198, lo que hace que el trabajo de apagado sea "insustituible".


No puedo actualizar :(
Martin

Debo descubrir los conflits y arreglarlos
Martin

1

Tal vez el intercambio todavía está activo cuando se alcanza el "Apagado objetivo"; Mi solución fue forzar la desactivación de intercambio antes de reiniciar:

swapoff -a
swapoff /dev/md6

después de eso, el reinicio me fue bien sin ninguna pausa.

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.