Perché systemd si blocca durante il riavvio?

13

1 su 10 volte, systemd si blocca durante il riavvio. Non capisco il motivo. Cosa / dove dovrei guardare per risolvere il problema? Sto usando systemd v196 e non riesco ad aggiornarlo alla versione> = 198 perché quest'ultimo richiede un kernel recente (con supporto per cgroups), che non può essere aggiornato dalle esigenze del cliente. Mi chiedo se esiste un modo ragionevole per scoprire la ragione di questo comportamento e far riavviare il sistema incondizionatamente.

Nota che questo link non aiuta: http://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1

Come puoi leggere lì:

Lo spegnimento non finisce mai

Se il normale riavvio o spegnimento non termina mai anche dopo aver atteso qualche minuto, il metodo sopra descritto per creare il registro di arresto non sarà di aiuto e il registro deve essere ottenuto utilizzando altri metodi. Due opzioni utili per il debug di problemi di avvio possono essere utilizzate anche per problemi di arresto:
use a serial console
use a debug shell - not only is it available from early boot, it also stays active until late shutdown.

Sto usando la console seriale, e per qualche motivo posso persino effettuare il login, poiché l'interfaccia eth è attiva o è stata richiamata (dopo che si è verificata una disconnessione durante le fasi di riavvio).

Non vedo il 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

Nota swap.target. È lì ma non usiamo affatto le partizioni di swap. Ho provato a mascherare lo scambio, ma il problema di blocco continua. L'ultima riga nella console è:

[OK] Stopped target shutdown.

EDIT: Come ho detto, posso accedere nuovamente tramite SSH su eth.

Ora ti mostrerò due registri. Il primo registro si verifica quando il riavvio / shutdwon si blocca, mentre il secondo registro è quando il riavvio ha esito positivo:

Caso di sospensione, l'output è sempre così (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>

Riavvio normale:

         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.

AGGIORNARE:

After some investigations and debug, I discovered the reason of the shutdown interruption, although I cannot still solve it. What happens is that for some reasons one of the custom services is started before the shutdown completes, which makes the shutdown procedure hang. That is one case of hang. Another kind of hang is when the shutdown is not interrupted but it stops at some point. For this reasons, before solving all the conflicts and other possible hangs one at a time, I want to unconditionally activate the hardware watchdog. To do this via systemd, I have enabled and tested, either separately or together, the RuntimeWatchdogSec and ShutdownWatchdogSec. Unfortunately, they did not help. By looking at the source code, it seems systemd enters in a loop where it still waits for all the fs to be unmounted and other kind of cleanups to be performed before letting the watchdog really be effective (without keeping it alive).

Sono bloccato. Quello che ti chiedo è di trovare un modo per: 1. avere il watchdog abilitato incondizionatamente almeno a partire dal punto in cui ha inizio l'arresto 2. rilevato e risolvere tutti i conflitti in modo semplice

La prima soluzione è preferita.

linux systemd

— balestruccio
fonte

Sta scendendo? Puoi condividere con noi quali servizi sono abilitati sul sistema? Qualcuno su misura? Come hai concluso che systemd si blocca?

— MattBianco,

@MattBianco Ho modificato la domanda. Ci sono più informazioni

— Martin,

Perché non vedo alcuna riga uguale tra il primo e il secondo registro? Sarei in grado di offrire più aiuto se potessi vedere dove iniziano a differire.

— BenjiWiebe,

@BenjiWiebe hai ragione. Modificherò di nuovo la domanda

— Martin,

provare a utilizzare journalctl come root e cercare timeout, errori e guasti di dipendenza nel journal di systemd.

— harrymc,

5

Mi permetto di suggerire una soluzione: prova ad aggiungere

  Before=basic.target

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

Sono colpito da una stranezza, nei tuoi registri, che mi ricorda un incidente di cui ho letto qualche tempo fa, nei forum Arch Linux : questo sistema si bloccherebbe al riavvio. La soluzione è stata offerta come sopra, per il motivo che il blocco sarebbe stato causato da un servizio che cercava di parlare con d-bus dopo che era stato interrotto:

Quindi, ordinandolo prima del basic.target, non solo inizia prima del raggiungimento del target di base, ma garantisce anche che rimanga intorno fino a quando il basic.target viene disattivato durante l'arresto.

Nel tuo registro non integro, vediamo infatti che il sistema di base non viene arrestato, mentre è correttamente arrestato nel registro integro .

Questo non dovrebbe funzionare e, considerando che non è possibile eseguire l'aggiornamento, hai preso in considerazione un downgrade?

— MariusMatutiae
fonte

1

Grazie, proverò la tua soluzione. Ho considerato un sostituto del buon vecchio SysV, dal momento che systemd sembra essere infastidito dal design.

— Martin,

Lo ottengo da systemd all'avvio dopo aver applicato la modifica: Ciclo di ordinazione trovato, salta il bus dei messaggi di sistema D-Bus. Qualche idea?

— Martin,

@Martin 1: hai / e / usr su partizioni separate? 2) hai un sacco di roba in /etc/init.d? O in /etc/rc.d?

— MariusMatutiae,

1

questo funziona alla grande su Ubuntu 16.04, il file era in /usr/lib/systemd/user/dbus.servicesotto [Unit]sezione

— Anwar

3

shutdown.targetè in conflitto con tutte le altre unità per impostazione predefinita, al fine di arrestarle automaticamente all'avvio del processo di spegnimento. Funziona anche nell'altro modo: se si avvia un'altra unità, si shutdown.targetarresta. Quindi il problema è che qualcosa fa sì che qualcosa si avvii durante l'arresto, che sovrascrive il processo di arresto.

Ciò avrebbe dovuto essere risolto in systemd v198, il che rende il processo di arresto "insostituibile".

— user1686
fonte

Non riesco ad aggiornare :(

— Martin,

Devo scoprire i conflitti e risolverli

— Martin,

1

Forse lo swap è ancora attivo quando si raggiunge "Arresto target"; La mia soluzione era forzare la disattivazione dello scambio prima del riavvio:

swapoff -a
swapoff /dev/md6

dopo ciò, il riavvio è andato bene per me senza alcuna pausa.

— Stéphane Peters
fonte