Dlaczego systemd zawiesza się podczas ponownego uruchamiania?

1 z 10 razy, systemd zawiesza się podczas restartu. Nie rozumiem powodu. Na co / gdzie powinienem spojrzeć, aby rozwiązać problem? Korzystam z systemd v196 i nie mogę go zaktualizować do wersji> = 198, ponieważ ten ostatni wymaga najnowszego jądra (z obsługą cgroups), którego nie można zaktualizować zgodnie z wymaganiami klienta. Zastanawiam się, czy istnieje rozsądny sposób, aby odkryć przyczynę takiego zachowania i sprawić, aby systemd ponownie uruchomił system bezwarunkowo.

Zauważ, że ten link nie pomaga: http://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1

Jak możesz tam przeczytać:

Zamykanie nigdy się nie kończy

Jeśli normalne ponowne uruchomienie lub wyłączenie zasilania nigdy się nie zakończy nawet po odczekaniu kilku minut, powyższa metoda utworzenia dziennika zamknięcia nie pomoże i dziennik należy uzyskać przy użyciu innych metod. Dwie opcje przydatne przy debugowaniu problemów z uruchamianiem mogą być również używane w przypadku problemów z zamykaniem:

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

Korzystam z konsoli szeregowej iz jakiegoś powodu mogę się nawet zalogować, ponieważ interfejs eth został uruchomiony lub został wywołany (po rozłączeniu nastąpił podczas kroków restartu).

Nie widzę powodu.

# 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

Zwróć uwagę na swap.target. Jest tam, ale w ogóle nie używamy partycji wymiany. Próbowałem zamaskować swap, ale problem z zawieszaniem się resetuje. Ostatni wiersz w konsoli to:

[OK] Stopped target shutdown.

EDYCJA: Jak powiedziałem, mogę ponownie zalogować się przez ssh przez eth.

Teraz pokażę ci dwa dzienniki. Pierwszy dziennik ma miejsce, gdy restart / shutdwon zawiesza się, a drugi dziennik jest, gdy ponowne uruchomienie się powiedzie:

Hang case, dane wyjściowe są zawsze takie (pełny dziennik):

[  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>

Normalny restart:

         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.

AKTUALIZACJA:

Po kilku śledztwach i debugowaniu odkryłem przyczynę przerwania wyłączania, chociaż nadal nie mogę go rozwiązać. Z pewnych powodów jedna z usług niestandardowych jest uruchamiana przed zakończeniem zamykania, co powoduje zawieszenie procedury zamykania. To jest jeden przypadek zawieszenia. Innym rodzajem zawieszenia jest to, że wyłączenie nie jest przerywane, ale w pewnym momencie zatrzymuje się. Z tego powodu, zanim rozwiążę wszystkie konflikty i inne możliwe zawieszenia pojedynczo, chcę bezwarunkowo aktywować sprzętowego watchdoga. Aby to zrobić poprzez systemd, włączyłem i przetestowałem, osobno lub razem, RuntimeWatchdogSec i ShutdownWatchdogSec. Niestety nie pomogły. Patrząc na kod źródłowy,

Utknąłem. Proszę o znalezienie sposobu na: 1. włączenie bezwzględnego włączenia watchdoga przynajmniej od momentu rozpoczęcia zamykania 2. wykrycie i rozwiązanie wszystkich konfliktów w łatwy sposób

Preferowane jest pierwsze rozwiązanie.

Zaryzykuję zaproponowanie rozwiązania: spróbuj dodać

  Before=basic.target

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

Uderza mnie dziwność w twoich logach, która przypomina mi wypadek, o którym czytałem jakiś czas temu, na forach Arch Linux : ten system zawiesiłby się przy ponownym uruchomieniu. Rozwiązanie zostało zaoferowane jak wyżej, na tej podstawie, że zawieszenie będzie spowodowane przez jakąś usługę próbującą porozmawiać z d-bus po jego zatrzymaniu:

Zatem, zamawiając go przed plikiem basic.target, nie tylko zaczyna się on przed osiągnięciem podstawowego celu, ale także zapewnia, że ​​pozostanie w nim do momentu, gdy podstawowy.target zostanie wyłączony podczas zamykania.

W twoim niezdrowym dzienniku widzimy, że system podstawowy nie jest zatrzymywany, podczas gdy jest prawidłowo zatrzymywany w zdrowym dzienniku.

Czy to nie powinno działać, a biorąc pod uwagę, że nie możesz dokonać aktualizacji, czy rozważałeś obniżenie wersji?

shutdown.targetdomyślnie powoduje konflikty ze wszystkimi innymi jednostkami, aby automatycznie je zatrzymać po rozpoczęciu procesu zamykania. Działa to również w drugą stronę - jeśli uruchomi się inna jednostka, spowoduje shutdown.targetzatrzymanie. Problem polega na tym, że coś powoduje uruchomienie się podczas zamykania, co zastępuje proces zamykania.

Powinno to zostać naprawione w systemd v198, co sprawia, że ​​zadanie zamknięcia jest „niezastąpione”.

Być może zamiana jest nadal aktywna po osiągnięciu „Docelowego wyłączenia”; Moim rozwiązaniem było wymuszenie dezaktywacji wymiany przed ponownym uruchomieniem:

swapoff -a
swapoff /dev/md6

po tym zrestartowałem się bez problemu.