12

1 из 10, systemd зависает при перезагрузке. Я не понимаю причину. Что / где я должен посмотреть, чтобы решить проблему? Я использую systemd v196 и не могу обновить его до версии> = 198, потому что для последнего требуется последнее ядро (с поддержкой cgroups), которое не может быть обновлено в соответствии с требованиями заказчика. Интересно, есть ли разумный способ выяснить причину такого поведения и заставить systemd перезагрузить систему безоговорочно.

Обратите внимание, что эта ссылка не помогает: 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. Это там, но мы не используем разделы подкачки вообще. Я пытался замаскировать своп, но проблема зависания переоценила. Последняя строка в консоли:

[OK] Stopped target shutdown.

РЕДАКТИРОВАТЬ: Как я уже сказал, я могу повторно войти через 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. К сожалению, они не помогли. Глядя на исходный код, кажется, что systemd входит в цикл, в котором он все еще ожидает отключения всех файловых систем и выполнения других видов очистки, прежде чем позволить сторожевому устройству действительно работать (не поддерживая его).

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

Первое решение является предпочтительным.

3 ответа3

4

Рискну предложить решение: попробуйте добавить

  Before=basic.target

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

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

Таким образом, заказывая его перед basic.target, он не только запускается до того, как базовая цель достигнута, но и гарантирует, что он остается до тех пор, пока не будет сбит basic.target во время выключения.

В вашем нездоровом журнале мы видим, что базовая система не остановлена, в то время как она правильно остановлена в исправном журнале.

Если это не сработает, и, учитывая, что вы не можете обновить, рассматривали ли вы понижение?

3

shutdown.target конфликтует со всеми другими устройствами по умолчанию, чтобы автоматически останавливать их при запуске процесса выключения. Это работает и по-другому - если запускается другое устройство, это приводит к shutdown.target . Таким образом, проблема в том, что что- то заставляет что-то запускаться во время выключения, что переопределяет процесс выключения.

Это должно быть исправлено в systemd v198, что делает работу выключения "незаменимой".

1

Возможно, своп по-прежнему активен при достижении "Целевого выключения"; Моим решением было принудительно отключить своп до перезагрузки:

swapoff -a
swapoff /dev/md6

после этого перезагрузка прошла нормально для меня без паузы.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .