Por que o systemd trava durante a reinicialização?

Question

1 de 10 vezes, o systemd trava durante a reinicialização. Eu não entendo o motivo. Para onde devo olhar para corrigir o problema? Estou usando o systemd v196 e não posso atualizá-lo para a versão > = 198 porque o último requer um kernel recente (com suporte para cgroups), que não pode ser atualizado pelos requisitos do cliente. Gostaria de saber se existe uma maneira razoável de descobrir o motivo desse comportamento e fazer o systemd reiniciar o sistema incondicionalmente.

Observe que este link não ajuda: link

Como você pode ler lá:

Shutdown Never Finishes

If normal reboot or poweroff never finish even after waiting a few minutes, the above method to create the shutdown log will not help and the log must be obtained using other methods. Two options that are useful for debugging boot problems can be used also for shutdown problems:

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

Estou usando o console serial e, por algum motivo, posso até fazer o login, pois a interface eth está ativa ou foi ativada (depois que uma desconexão aconteceu durante as etapas de reinicialização).

Eu não vejo o 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

Observe o swap.target. Está lá, mas não usamos partições de swap. Eu tentei mascarar swap, mas o problema de travar reamins. A última linha no console é:

[OK] Stopped target shutdown.

EDIT: Como eu disse, eu posso fazer o login novamente via ssh sobre eth.

Agora vou mostrar dois logs para você. O primeiro log acontece quando o reboot / shutdwon trava, enquanto o segundo log é quando a reinicialização é bem-sucedida:

Desligue o caso, a saída é sempre assim (log 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>

Reinicialização 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.

ATUALIZAÇÃO:

Após algumas investigações e depurações, descobri o motivo da interrupção do desligamento, embora ainda não consiga resolvê-lo. O que acontece é que, por alguns motivos, um dos serviços personalizados é iniciado antes da conclusão do desligamento, o que torna o procedimento de desligamento interrompido. Esse é um caso de jeito. Outro tipo de interrupção é quando o desligamento não é interrompido, mas pára em algum momento. Por esse motivo, antes de resolver todos os conflitos e outras possíveis pendências, uma por vez, desejo ativar incondicionalmente o watchdog de hardware. Para fazer isso via systemd, eu ativei e testei, separadamente ou em conjunto, o RuntimeWatchdogSec e o ShutdownWatchdogSec. Infelizmente, eles não ajudaram. Ao olhar para o código fonte, parece que o systemd entra em um loop onde ainda espera que todos os fs sejam desmontados e outros tipos de limpeza sejam executados antes de deixar o watchdog realmente efetivo (sem mantê-lo ativo).

Estou preso. O que eu peço é que você encontre uma maneira de: 1. ter o watchdog ativado incondicionalmente pelo menos a partir do ponto onde o desligamento começa 2. detectou e resolveu todos os conflitos de uma forma fácil

A primeira solução é a preferida.

    

Answer 1

shutdown.target conflita com todas as outras unidades por padrão, a fim de interrompê-las automaticamente quando o processo de desligamento é iniciado. Isso funciona da outra maneira também - se outra unidade iniciar, isso fará com que shutdown.target seja interrompido. Portanto, o problema é que algo faz com que algo seja iniciado durante o desligamento, o que substitui o processo de desligamento.

Isso deve ter sido corrigido no systemd v198, o que torna o trabalho de desligamento "insubstituível".

    

Answer 2

Eu me atrevo a sugerir uma solução: tente adicionar

  Before=basic.target

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

Eu sou surpreendido por uma esquisitice, em seus registros, que me faz lembrar de um acidente que eu li há algum tempo, nos fóruns do Arch Linux : este sistema travaria na reinicialização. A solução foi oferecida como acima, com base no fato de que o travamento seria causado por algum serviço que tentasse falar com o d-bus depois que ele fosse interrompido:

So by ordering it before the basic.target it not only starts before the basic target is reached, but also ensures that it stays around until after the basic.target is brought down during shutdown.

Em seu log insalubre , vemos que o Sistema Básico não é interrompido, enquanto está corretamente parado no log saudável .

Se isso não funcionar, e considerando que você não pode atualizar, você considerou um downgrade?

    

Answer 3

Talvez a troca ainda esteja ativa ao atingir o "encerramento do destino". Minha solução foi forçar a desativação de swap antes da reinicialização:

swapoff -a
swapoff /dev/md6

depois disso, a reinicialização correu bem para mim sem qualquer pausa.