Systemd-analyze verify multi-user.target показывает разное количество циклов упорядочивания каждый раз, когда я его запускаю.

Вопрос или проблема

У меня есть некоторые проблемы с загрузкой новой версии Ubuntu 24.04.1 с Intel Optane (которую я только что получил с ebay): процесс загрузки проходит быстро, но время от времени некоторые единицы systemd не запускаются во время загрузки, система загружается без NetworkManager или чего-то подобного, как snapd-apparmor. Журнал журналctl сообщает о наличии циклов упорядочивания. Пытаясь их найти, я заметил, что systemd-analyze verify multi-user.target сообщает разные вещи почти каждый раз, когда я его запускаю:

$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
7
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
13
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
0
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
0
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
18

Заподозрив диск с ebay, я попробовал то же самое на ранее установленной Ubuntu 22.04 на Corsair NVMe, с теми же результатами:

$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
16
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
22
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
44
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
24
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
4
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo | wc -l
14

Процесс загрузки на Corsair NVMe имеет аналогичные проблемы с не запуском некоторых единиц systemd. Но это происходит реже.

Почему это происходит? Я что-то упускаю в systemd-analyze verify? Как так получается, что systemd-analyze verify может сообщать разное количество циклов каждый раз, когда вы его запускаете?

Версии. На Intel Optane:

$ systemd --version
systemd 255 (255.4-1ubuntu8.4)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=24.04
DISTRIB_CODENAME=noble
DISTRIB_DESCRIPTION="Ubuntu 24.04.1 LTS"

И предыдущее установка на Corsair NVMe (lspci фактически сообщает о нем как о Phison Electronics Corporation E12):

$ systemd --version
systemd 249 (249.11-0ubuntu3.12)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY -P11KIT -QRENCODE +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.5 LTS"

Ответ или решение

При работе с утилитой systemd-analyze verify multi-user.target, отображение различных чисел циклов при каждом запуске может быть обусловлено несколькими факторами, связанными как со спецификой работы systemd, так и с состоянием системы.

Почему возникают различные числа циклов?

  1. Параллелизм и гонки условий:
    systemd проектирован для высокой производительности и параллельного выполнения сервисов. Это может привести к тому, что различные единицы (units) системы могут находиться в состоянии гонки, когда их зависимости неявно меняются между вызовами verify. Если некоторые сервисы ещё не завершили свою инициализацию, при повторном запуске команды проверка зависимостей может дать разные результаты.

  2. Проблемы с конфигурацией:
    Если в конфигурации системных единиц (например, в сервисах NetworkManager, snapd) есть циклы или неправильные зависимости, это может привести к тому, что их состояние будет непостоянным. Грубые ошибки в конфигурации могут вызывать проблемы на уровне зависимостей, что объясняет изменение числа циклов.

  3. Состояние системы:
    Временные факторы, такие как загрузка диска или задержки операции ввода-вывода, могут также создать впечатление нестабильности. Эта нестабильность может постигать не только сервисы, но и возвращаемое systemd состояние, что может привести к изменениям в выводе команды.

  4. Изменения в состоянии юнитов:
    При каждом выполнении systemd-analyze verify состояние юнитов может изменяться, в зависимости от того, были ли они завершены, перезагружены или изменены. Если какой-либо из юнитов устанавливает зависимость или выполняет другие действия в зависимости от текущего состояния системы, это также может влиять на результаты.

Как действовать в такой ситуации?

  1. Проверка журналов:
    Используйте journalctl -b для просмотра ошибок или предупреждений, которые могут указывать на проблемы в инициализации системы. Обратите внимание на сообщения об ошибках, появляющиеся при старте сервисов, которые не запускаются.

  2. Изучение зависимостей юнитов:
    Проанализируйте зависимости юнитов с помощью команды systemctl list-dependencies multi-user.target, чтобы выяснить, какие сервисы и юниты могут влиять на стабильность загрузки.

  3. Обновление и исправление конфигураций:
    Убедитесь, что все системы и конфигурации обновлены. Особенно это касается сетевых сервисов, таких как NetworkManager, так как их конфигурации могут требовать корректировок для оптимизации.

  4. Тестирование на другом диске:
    Поскольку у вас есть подозрения на диск Intel Optane, попробуйте провести тесты на другом носителе, измените при этом параметры BIOS, такие как режимы работы диска, и сравните результаты.

  5. Использование утилиты systemd-analyze critical-chain:
    Эта команда позволит вам визуализировать зависимости загрузки и времени инициализации юнитов, что может оказаться полезным для поиска проблем.

Заключение

Разнообразие результатов при запуске systemd-analyze verify multi-user.target может быть связано с параллелизмом в системе, неправильными или конфликтующими конфигурациями, а также различным состоянием системы. Процесс диагностики требует тщательного анализа журналов, проверки зависимостей и, возможно, тестирования конфигураций на других устройствах хранения. Следуя указанным рекомендациям, вы сможете выявить возможности оптимизации и решения проблем с загрузкой системы на ваших устройствах.

Оцените материал
Добавить комментарий

Капча загружается...