Чому systemd висить під час перезавантаження?

1 з 10 разів, systemd висить під час перезавантаження. Я не розумію причини. Що / де слід звернути увагу, щоб виправити проблему? Я використовую systemd v196 і не можу оновити його до версії> = 198, оскільки для цього потрібне останнє ядро ​​(з підтримкою для груп), яке не може бути оновлено за вимогами замовника. Цікаво, чи є розумний спосіб виявити причину такої поведінки і змусити системного перезавантажити систему беззастережно.

Зауважте, що це посилання не допомагає: http://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1

Як ви можете прочитати там:

Вимкнення ніколи не закінчується

Якщо звичайна перезавантаження або перезапуск ніколи не закінчується, навіть не чекаючи декількох хвилин, вищевказаний спосіб створення журналу відключення не допоможе, і журнал повинен бути отриманий іншими методами. Два варіанти, які корисні для налагодження проблем із завантаженням, можуть бути використані також для проблем із відключенням:

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

Я використовую послідовну консоль, і я чомусь можу навіть увійти в систему, оскільки інтерфейс eth його підняли або підняли (після відключення трапилось під час кроків перезавантаження).

Я не бачу причини.

# 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

Зверніть увагу на swap.target. Він є, але ми взагалі не використовуємо swap-розділи. Я спробував замаскувати своп, але проблема з повішенням переглядається. Останній рядок у консолі:

[OK] Stopped target shutdown.

EDIT: Як я вже сказав, я можу повторно ввійти через ssh через eth.

Зараз я покажу вам два журнали. Перший журнал відбувається, коли перезавантаження / shutdwon зависає, тоді як другий журнал - при успішному перезавантаженні:

Випадковий завіса, вихід завжди такий (повний журнал):

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

Звичайна перезавантаження:

         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.

ОНОВЛЕННЯ:

Після деяких розслідувань та налагодження я виявив причину припинення відключення, хоча досі не можу її вирішити. Що стається, це те, що з певних причин одна з користувацьких служб запускається до завершення відключення, через що процедура вимкнення зависає. Це один випадок зависання. Інший вид зависання - це коли зупинка не припиняється, але вона зупиняється в якийсь момент. З цієї причини, перш ніж вирішити всі конфлікти та інші можливі зависання по черзі, я хочу беззастережно активувати апаратну сторожу. Для цього через systemd я включив і протестував окремо або разом RuntimeWatchdogSec і ShutdownWatchdogSec. На жаль, вони не допомогли. Переглядаючи вихідний код,

Я застряг. Я прошу вас - знайти спосіб для того, щоб: 1. включити сторожовий дог беззастережно, принаймні, починаючи з того моменту, коли починається відключення 2. виявити та вирішити всі конфлікти простим способом

Перше рішення є кращим.

Я ризикую запропонувати рішення: спробуйте додати

  Before=basic.target

до /usr/lib/systemd/system/dbus.service.

Мене вражає дивність у ваших журналах, яка нагадує мені про нещасний випадок, про який я читав деякий час тому на форумах Arch Linux : ця система зависла б при перезавантаженні. Рішення було запропоновано, як зазначено вище, з тієї причини, що зависання спричинить якась служба, яка намагається поговорити з d-bus після її зупинки:

Таким чином, замовляючи його перед basic.target, він не тільки запускається до досягнення базової мети, але й гарантує, що він залишатиметься до тих пір, поки не буде знищено basic.target під час відключення.

У вашому нездоровому журналі ми бачимо фактично, що Основна система не зупинена, а вона належним чином зупинена у здоровому журналі.

Якщо це не спрацює, і вважаючи, що ви не можете оновити, чи вважали ви зменшення кваліфікації?

shutdown.targetконфліктує з усіма іншими підрозділами за замовчуванням, щоб автоматично зупинити їх при запуску процесу відключення. Це працює і іншим способом - якщо запускається інший пристрій, воно shutdown.targetзупиняється. Тож проблема полягає в тому, що щось змушує запускатись під час відключення, що перекриває процес відключення.

Це повинно було бути зафіксовано в systemd v198, що робить роботу відключення "незамінною".

Можливо, своп все ще активний при досягненні "Цільового відключення"; Моє рішення полягало в тому, щоб змусити деактивацію заміни перед перезавантаженням:

swapoff -a
swapoff /dev/md6

після цього перезавантаження пройшло непогано для мене без пауз.