SDB:Systemd

Systemd

Использование systemd - Статус внедрения systemd - Управление работой Systemd - Сборка пакетов с поддержкой systemd - Systemd services collection

systemd — новая система инициализации для Linux, совместимая с SysV и LSB сценариями, обеспечивающая параллельное выполнения сервисов в процессе загрузки.

Внимание: Версия openSUSE 12.3. Все системные службы systemd перемещены в директорию /usr/.

Основные элементы

systemd запускает и контролирует все системные службы. В ее основе лежит понятие "единиц" (units), которые связаны между собой и имеют определенное имя и тип с соответствующими конфигурационными файлами, т. е. это файлы конфигурации хранящие информацию о сервисе, сокете, устройстве и т. д. Каждая единица может требовать другие единицы (Requires), конфликтовать с ними (Conflicts), запускаться до (After) или после (Before) определенной единицы.

Существуют следующие виды единиц:

service — стандартные демоны, которые могут быть запущены, остановлены и перезагружены. В качестве таких сервисов могут быть использованы SysV-сценарии.
socket — файл конфигурации сокета файловой системы или сети, связанный с определенным сервисом, т. е. каждая сокет-единица имеет соответствующий файл обслуживания *.service, который запускается при попытке установки соединения с сокетом, например, сетевому порту. Поддерживает классический FIFO транспорт (man fifo).
device — файл конфигурации содержащий правило udev для обработки дерева устройств.
mount — точки монтирования в иерархии файловой системы. Также поддерживается получение информации о файловых системах из файла /etc/fstab.
automount — автоматическое монтирование файловой системы при обращении к каталогу.
target — логическая группировка единиц, т.е. сам по себе ничего не делает, а просто ссылается на другие единицы, которые в итоге могут управляться совместно. Например, multi-user.target в классической системе инициализации SysV соответствует 5-му уровню выполнения или bluetooth.target — запускает службы, когда какое-то Bluetooth-устройство становится доступным.
snapshot — снимок конфигурации единиц (units). По аналогии с вышеприведенной целевой единицей, сам ничего не делает и его единственная цель — создание ссылок на другие единицы. Позволяет восстанавливать список ранее запущенных служб, например, после временного запуска/остановки службы и т.д.
timer — активация других единиц по таймеру, предоставляет функционал, похожий на сron.
swap — управление разделами и файлами подкачки. Похожа на точки монтирования *.mount.
path — активация других служб на основе изменений в файловой системе (inotify).

Уровни загрузки

Концепция systemd по сути схожа с уровнями выполнения (runlevel), но работающая немного по другому. Systemd использует понятие "целей" (target), каждая из которых имеет определенное имя и назначение, с возможностью одновременной работы с несколькими из них, например, для того, чтобы выяснить текущий уровень выполнения нужно выполнить:

$ systemctl list-units --type=target

Обратите внимание, что активной может быть более чем одна цель. Поэтому вопрос относительно уровней выполнения, возможно не имеет смысла, и вышеприведенная команда позволяет выяснить все цели, которые активны в настоящий момент.

Уровень загрузки SysV	Цель systemd	Описание
0	runlevel0.target, poweroff.target	Остановка системы
1, s, single	runlevel1.target, rescue.target	Однопользовательский режим (single user mode). Базовая система сконфигурирована, но демоны не запущены.
2	runlevel2.target, multi-user.target	Пользовательский/Специфический уровень. Сконфигурирован также как уровень выполнения 3, но без поддержки сети
3	runlevel3.target, multi-user.target	Многопользовательский режим (multiuser mode) с поддержкой сети
4	runlevel4.target, multi-user.target	Не используется
5	runlevel5.target, graphical.target	Многопользовательский графический режим с поддержкой сети
6	runlevel6.target, reboot.target	Перезагрузка системы
emergency	emergency.target	Аварийный режим, который является аналогом 1-го уровня

Как уже отмечалось выше, в systemd уровни выполнения доступны через "целевые единицы". Сменить текущий уровень выполнения можно с помощью следующей команды:

# systemctl isolate runlevel3.target

Заметьте, что понятие уровней загрузки (runlevel) устарело, и, как правило, лучше воспользоваться современным именем, например:

# systemctl isolate multi-user.target

Уровни выполнения (runlevel) эмулируются целевыми единицами (target), т.е. являются символическими ссылками, например, runlevel3.target -> multi-user.target.

Для изменения уровня загрузки по умолчанию, используйте символические ссылки или systemctl, например:

переключиться на 3-ий уровень выполнения:

# ln -sf /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target

или

# systemctl enable multi-user.target

переключиться на 5-ый уровень выполнения:

# ln -sf /usr/lib/systemd/system/graphical.target /etc/systemd/system/default.target

или

# systemctl enable graphical.target

Метод изменения уровня загрузки с помощью systemctl возможен только, если целевой файл конфигурации содержит следующие строки:

[Install]
Alias=default.target

В настоящий момент вышеприведенные строки присутствуют в нескольких файлах (целевых единиц): multi-user.target, graphical.target.

Обратите внимание, что systemd игнорирует файл /etc/inittab.

Инструменты

systemctl — менеджер управления службами, используемый для анализа и контроля состояния systemd.
systemd-cgls — рекурсивное отображение содержимого выбранной иерархии контрольных групп (cgroups).
systemadm — графический интерфейс системного менеджера systemd (systemd-gtk), который на данный момент находится в стадии разработки (по умолчанию не установлен).
systemd-analyze — утилита, выводящая список единиц systemd, активированных во время загрузки, с указанием длительности загрузки для каждой из них (по умолчанию не установлен).
systemd-journalctl — инструмент ведения журналов событий.

Для просмотра списка инструментов systemd воспользуйтесь дополнением символов до исполняемой команды systemd-<Tab>.

systemctl

systemctl — централизованное средство управления службами (и не только) являющееся основным инструментом. При использовании systemctl всегда необходимо указывать полное имя файла (единицы), в том числе суффикс (например, bluetooth.target). Далее приводится ряд наиболее часто используемых команд. Для просмотра дополнительных опций обратитесь к странице руководства man systemctl.

Просмотр списка запущенных единиц:

$ systemctl 
UNIT                       LOAD   ACTIVE SUB     JOB DESCRIPTION 
accounts-daemon.service    loaded active running     Accounts Service 
atd.service                loaded active running     Job spooling tools 
avahi-daemon.service       loaded active running     Avahi mDNS/DNS-SD Stack 
bluetooth.service          loaded active running     Bluetooth Manager 
colord-sane.service        loaded active running     Daemon for monitoring attached scanners and registering them with colord 
colord.service             loaded active running     Manage, Install and Generate Color Profiles 
crond.service              loaded active running     Command Scheduler 
cups.service               loaded active running     CUPS Printing Service 
dbus.service               loaded active running     D-Bus System Message Bus 
...

Просмотр списка единиц, запуск которых завершился неудачей:

$ systemctl --failed

Просмотр списка активных служб:

$ systemctl list-units --type=service

Запуск, остановка и перезапуск служб:

# systemctl start|stop|restart <service>

Доступные единицы или службы можно посмотреть в виде дерева (tree): tree /etc/systemd/system и tree /usr/lib/systemd/system, первый список имеет более высокий приоритет.

Перезагрузка конфигурации без перезапуска службы:

# systemctl reload <service>

Текущее состояние службы:

$ systemctl status cron.service
cron.service - Command Scheduler
          Loaded: loaded (/usr/lib/systemd/system/cron.service; enabled)
          Active: active (running) since Fri, 06 Jul 2012 18:18:34 +0300; 11h ago
        Main PID: 3789 (cron)
          CGroup: name=systemd:/system/cron.service
                  └ 3789 /usr/sbin/cron -n

Проверка, будет ли запущена служба при загрузке системы:

$ systemctl is-enabled cron.service 
enabled

Включение/отключение автоматического запуска службы при загрузке системы, соответственно:

# systemctl {enable,disable} <service>

Сообщить systemd об изменении конфигурации, т.е. перечитать конфигурацию:

# systemctl daemon-reload

Зависимости необходимые единице, например, для целевой единицы multi-user.target:

$ systemctl show -p "Wants" multi-user.target 
Wants=systemd-update-utmp-runlevel.service syslog.service cron.service avahi-daemon.service acpid.service remote-fs.target systemd-user-sessions.service systemd-ask-password-wall.path getty.target rc-local.service bootsplash-quit.service systemd-logind.service dbus.service rng-tools.service microcode.ctl.service fbset.service splash.service cpufreq.service splash_early.service sbl.service brld.service vboxadd.service network.service SuSEfirewall2_init.service nscd.service vmtoolsd.service SuSEfirewall2_setup.service purge-kernels.service network-remotefs.service

Вместо "Wants" можно также попробовать "WantedBy", "Requires", "RequiredBy", "Conflicts", "ConflictedBy", "Before", "After" для соответствующих видов зависимостей и их противоположностей.

systemd-cgls

cgroups — это контрольные группы распределяющие между процессами ресурсы и позволяющие осуществлять контроль, приоритизацию и управление системными ресурсами. Контрольные группы организованы иерархически, где каждый процесс помещается в группу с именем родителя, породивший этот процесс. Это позволяет установить точное происхождение определенного процесса.

systemd-cgls — это утилита, позволяющая наглядно оценить принадлежность группы процессов к их службам или процессов вошедших в сеанс пользователя с помощью регистрации пользовательских сессий (pam_systemd)

$ systemd-cgls 
 ├   2 [kthreadd] 
 ├   3 [ksoftirqd/0] 
 ├   4 [migration/0] 
 ├   5 [migration/1] 
 ... 
 ├ 718 [usb-storage] 
 ├ user 
 │ └ kay 
 │   └ 1 
 │     ├   802 /usr/lib/gdm/gdm-session-worker 
 │     ├   878 /usr/bin/gnome-session 
 │     ├ 19199 /bin/bash 
 │     ├ 19209 systemd-cgls 
 │     ├ 30209 /bin/bash 
 │     └ 30234 xchat 
 └ systemd-1 
...

Подробности о службах, процессах и управления ресурсами Вы можете узнать здесь

systemd-analyze

systemd-analyze — это инструмент помогающий найти виновников медленной загрузки системы.

Для просмотра суммарного времени загрузки:

$ systemd-analyze
Startup finished in 3930ms (kernel) + 19097ms (userspace) = 23028ms

где kernel — время потраченное на инициализацию ядра, а userspace — время запуска служб из пространства пользователя.

Для получения древовидного списка профилирования единиц (выявления медленных по времени):

$ systemd-analyze critical-chain  
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @30.470s
└─multi-user.target @30.470s
  └─dkms_autoinstaller.service @13.361s +17.107s
    └─basic.target @11.357s
      └─timers.target @11.347s
        └─systemd-tmpfiles-clean.timer @11.346s
          └─sysinit.target @11.345s
            └─apparmor.service @10.864s +480ms
                ...

Чтобы получить список активированных при загрузке единиц systemd, отсортированных по времени для каждой из них, выполните:

$ systemd-analyze blame 
3735ms systemd-vconsole-setup.service 
2570ms network.service 
1477ms localnet.service 
1016ms systemd-logind.service 
...

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

Для наглядности параллелизации служб воспользуйтесь графической диаграммой:

$ systemd-analyze plot > plot.svg

Более подробную информацию о виновниках медленной загрузки можно найти здесь.

systemd-journalctl

Начиная с версии v38+ systemd имеет собственную систему регистрации событий, которая по умолчанию включена в дистрибутив openSUSE 12.2+. systemd-journalctl является неотъемлемой частью systemd и не может использоваться отдельно. Журналы данного инструмента хранятся в бинарном виде в /var/log/journal, что исключает возможность просмотра содержимого данных файлов стандартными утилитами обработки текстовых данных. При вызове инструмента без параметров покажет все содержимое журнала аналогичного классической системе лог-файлов syslog ( /var/log/messages ):

# systemd-journalctl -a
Aug 07 00:53:17 dhcppc0 systemd-journal[8469]: Journal started
Aug 07 00:53:17 dhcppc0 systemd-logind[8472]: New seat seat0.
Aug 07 00:53:18 dhcppc0 systemd-logind[8472]: New session c11 of user root.
Aug 07 00:53:18 dhcppc0 systemd-logind[8472]: New session c1 of user aliaksei.
Aug 07 00:53:18 dhcppc0 systemd-logind[8472]: Linked /tmp/.X11-unix/X0 to /run/user/aliaksei/X11-display.
Aug 07 00:54:09 dhcppc0 systemd-logind[8472]: Removed session c11.
Aug 07 00:54:11 dhcppc0 systemd-logind[8472]: Removed session c1.
Aug 07 00:54:23 dhcppc0 systemd-logind[8472]: New session 25 of user 
Aug 07 00:54:23 dhcppc0 systemd-logind[8472]: Linked /tmp/.X11-unix/X0 to /run/user/aliaksei/X11-display.
Aug 07 00:54:23 dhcppc0 checkproc[8664]: checkproc: can not get session id for process 2042!
...

Обратите внимание, что запуск команды без привилегий суперпользователя покажет только локально сгенерированные сообщения, а сам ключ "-a, --all" - покажет все содержимое строк вне зависимости от геометрии экрана.

Для регистрации поступающей информации с выводом на экран в реальном времени отвечает параметр "-f --follow". За изменение уровня подробностей, а также формата вывода журнала используется параметр "--output=, -o", который по умолчанию соответствует short, т.е. классической системе лог-файлов, например, чтобы показать полную информацию элементов выполните:

# systemd-journalctl -o verbose
Tue, 07 Aug 2012 00:53:17 +0300 [s=093f834685e74abda2c6271ac27da4f6;i=1;b=6a7b24555f5c4e90a0eb8c58917f873d;m=51daf3b24;t=4c69fe7cc24da;x=1a30fe2a1c3ab3f5;p=system.journal]
        PRIORITY=5
        _TRANSPORT=driver
        MESSAGE=Journal started
        MESSAGE_ID=f77379a8490b408bbe5f6940505a777b
        _PID=8469
        _UID=0
        _GID=0
        _COMM=systemd-journal
        _EXE=/usr/lib/systemd/systemd-journald
        _CMDLINE=/usr/lib/systemd/systemd-journald
        _SYSTEMD_CGROUP=/system/systemd-journald.service
        _SYSTEMD_UNIT=systemd-journald.service
        _SELINUX_CONTEXT=[11B blob data]
        _BOOT_ID=6a7b24555f5c4e90a0eb8c58917f873d
        _MACHINE_ID=0bc1f7af3fdd6432b74e9169000003d3
        _HOSTNAME=dhcppc0
...

Присутствие systemd-journalctl позволяет также просматривать последние сообщения журнала для определенной службы, например:

# systemctl status avahi-daemon.service
avahi-daemon.service - Avahi mDNS/DNS-SD Stack
          Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; enabled)
          Active: active (running) since Thu, 13 Sep 2012 23:27:28 +0300; 56min ago
        Main PID: 500 (avahi-daemon)
          Status: "Server startup complete. Host name is linux-prr7.local. Local service cookie is 2876072416."
          CGroup: name=systemd:/system/avahi-daemon.service
                  └ 500 avahi-daemon: running [linux-prr7.local]

Sep 13 23:27:28 linux-prr7 avahi-daemon[500]: Loading service file /etc/avahi/services/udisks.service.
Sep 13 23:27:28 linux-prr7 avahi-daemon[500]: Network interface enumeration completed.
Sep 13 23:27:28 linux-prr7 avahi-daemon[500]: Registering HINFO record with values 'I686'/'LINUX'.
Sep 13 23:27:28 linux-prr7 avahi-daemon[500]: Server startup complete. Host name is linux-prr7.local. Local service cookie is 2876072416.
...

Структурирование отображаемой информации журнала обеспечивается параметрами в формате "переменная=значение", например, для просмотра всех сообщений от конкретной единицы выполните:

# systemd-journalctl _SYSTEMD_UNIT=avahi-daemon.service

Более подробную информацию о параметрах запуска systemd-journalctl, а также переменных Вы можете узнать из страницы руководства man systemd-journalctl, systemd.journal-fields.

Файлы конфигурации

Файл	Служба	Описание
/etc/locale.conf	systemd-localed.service	Конфигурация системной локали (по умолчанию отсутствует)
/etc/vconsole.conf	systemd-vconsole-setup.service	Конфигурация раскладки клавиатуры и консольного шрифта (по умолчанию отсутствует)
/etc/systemd/system.conf /etc/systemd/user.conf		Некоторые параметры конфигурации systemd. Чтобы посмотреть текущие настройки менеджера воспользуйтесь командой systemctl show
/etc/systemd/systemd-journald.conf	systemd-journald.service	Конфигурация службы журнала событий
/etc/systemd/systemd-logind.conf	systemd-logind.service	Конфигурация менеджера входа в систему
/etc/modules-load.d/.conf /usr/lib/modules-load.d/.conf	systemd-modules-load.service	Файлы принудительной загрузки модулей ядра во время загрузки системы
/etc/sysctl.d/.conf /usr/lib/sysctl.d/.conf	systemd-sysctl.service	Файлы параметров ядра sysctl ( Вы должны свериться с текущей страницей руководства man sysctl)
/etc/tmpfiles.d/.conf /usr/lib/tmpfiles.d/.conf	systemd-tmpfiles-setup.service systemd-tmpfiles-clean.service	Файлы конфигурации для временных файлов и директорий (создание, удаление и очистка), таких как /run или /tmp
/etc/binfmt.d/.conf /usr/lib/binfmt.d/.conf	systemd-binfmt.service	Регистрация дополнительных бинарных форматов исполняемых файлов (таких, как mono, wine и т.д.) во время загрузки

где файлы /etc/ имеют более высокий приоритет, и в случае обновления остаются неизменными.

Часто задаваемые вопросы

Как загрузиться в другой уровень выполнения?

По умолчанию при загрузке systemd активизирует целевую единицу default.target, работа которой заключается в загрузке служб и других единиц c учетом зависимостей. Эту цель по умолчанию можно изменить, добавив в командной строке ядра (параметры загрузки в меню GRUB Legacy или в строке ядра для GRUB 2) опцию systemd.unit= Это может быть использовано для однократной загрузки системы, например, чтобы загрузиться в 3-ий уровень выполнения (согласно классической системе инициализации), добавьте следующее:

systemd.unit=multi-user.target

Обратите внимание, что в настоящий момент для вышеприведенного уровня выполнения, вместо опции systemd.unit=, достаточно добавить только цифру 3.

Как настроить автоматический вход в систему на виртуальной консоли?

Создайте новый сервис аналогичный getty@.service:

# cp /usr/lib/systemd/system/getty@.service /etc/systemd/system/autologin@.service 
# ln -s /etc/systemd/system/autologin@.service /etc/systemd/system/getty.target.wants/getty@tty8.service

Отредактируйте следующие строки файла autologin@.service, например:

... 
ExecStart=-/sbin/mingetty --autologin USERNAME %I 
Restart=no 
... 
Alias=getty.target.wants/getty@tty8.service

Перезапустите конфигурацию менеджера systemd и запустите службу:

# systemctl daemon-reload 
# systemctl start getty@tty8.service

Обратите внимание, что если Вы выйдите с tty8 сессии, то не сможете использовать ее до следующей перезагрузки или ручного запуска, systemctl, за исключением, автоматической перезагрузки упавшей службы "Restart=always".

Как изменить количество работающих по умолчанию getty?

Создайте символическую ссылку на другой экземпляр getty в каталоге getty.target.wants/:

# ln -sf /usr/lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service 
# systemctl daemon-reload 
# systemctl start getty@tty9.service

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

# rm /etc/systemd/system/getty.target.wants/getty@tty5.service /etc/systemd/system/getty.target.wants/getty@tty6.service 
# systemctl daemon-reload 
# systemctl stop getty@tty5.service getty@tty6.service

Обратите внимание, что по умолчанию запускается только один getty-процесс, но при этом Вы можете запускать дополнительные процессы agetty, переключаясь на другой терминал вручную. Если же Вы хотите запретить переход на неиспользуемые по умолчанию терминалы, тогда раскомментируйте строку NautoVTs= файла /etc/systemd/systemd-logind.conf и укажите значение равное 0. Более подробную информацию о конфигурации менеджера входа в систему можно найти на странице руководства (man systemd-logind.conf).

Как заставить работать консоль на последовательном порту?

Создайте символическую ссылку в каталоге getty.target.wants/, согласно имени устройства, полученного с помощью dmesg | grep tty. Например, для первого устройства (ttyS0):

# ln -s /usr/lib/systemd/systemd/serial-getty@.service /etc/systemd/system/getty.target.wants/serial-getty@ttyS0.service

Как автоматически запустить службу на определенном уровне выполнения?

Создайте символические ссылки файла службы в необходимых каталогах, например, чтобы запустить службу foobar.service на 3-ем уровне выполнения (будет соответствовать каталогу multi-user.target.wants/):

# ln -sf /usr/lib/systemd/system/foobar.service /etc/systemd/system/multi-user.target.wants/foobar.service 
# systemctl daemon-reload

Какой файл для запуска службы имеет более высокий приоритет, systemd или SysV?

Если в системе присутствуют два файла для запуска службы, например, /usr/lib/systemd/system/foobar.service против /etc/init.d/foobar и оба файла доступны системе, то файл службы systemd имеет более высокий приоритет, чем SysV сценарий, при этом сам SysV сценарий игнорируются, независимо от того, как включается или отключается определенная служба. Обратите внимание, что запуская SysV сценарий, происходит автоматическое перенаправление (redirecting to systemctl).

Как изменить файл службы, который перезаписывается при обновления rpm пакета?

Скопируйте файл службы из /usr/lib/systemd/system в /etc/systemd/system и отредактируйте его там. Последний каталог имеет более высокий приоритет, и rpm никогда не перезапишет его. Если Вы хотите использовать распределенную файловую службу снова, то просто удалите/переименуйте файл службы в /etc/systemd/system.

Как выключить машину?

Вы можете использовать следующую команду:

$ systemctl poweroff

Для остановки системы, не выключая питания, воспользуйтесь:

$ systemctl halt

Если Вы находитесь в сессии локального пользователя и при этом никакого другого активного сеанса нет, то вышеприведенные команды будут работать без привилегий суперпользователя.

Как вернуть классическую систему инициализации SysV?

Нижеприведенные действия могут быть необходимы в openSUSE 12.2/12.1, где systemd используется по умолчанию.

Внимание: Удаление systemd. Делайте это с максимальной осторожностью, поскольку велик риск того, что система не загрузится.

Воспользуйтесь одним из нижеприведенных действий:

для однократной загрузки: в меню GRUB нажмите клавишу "F5" и выберите "System V"
на постоянной основе: добавьте в командной строке ядра init=/sbin/sysvinit с помощью GUI инструмента YaST или отредактировав один из файлов:

/boot/grub/menu.lst (grub-legacy) в строке kernel
/etc/default/grub (grub2) в строке GRUB_CMDLINE_LINUX_DEFAULT="" и после выполните: sudo /usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg

Обратите внимание, что инициализация init=/sbin/init, с установленным пакетом systemd-sysvinit, является символической ссылкой на systemd ( init -> ../lib/systemd/systemd ). Поэтому применение данного параметра загрузки возможно только после удаления systemd-sysvinit.

Документация

С полной документацией openSUSE о systemd можно ознакомиться перейди по этой ссылке.

Известные проблемы

Эта статья содержит фрагменты на иностранном языке. Вы можете помочь переведя её до конца. (cм. руководство по переводу)

Services not starting as expected

Even though chkconfig cron shows that cron should be enabled, it seems not to be started after boot. systemctl start cron.service starts it just fine. See Bug #660493.

systemctl enable cron.service helps here.

Цикличное монтирование (loop mounts) не работает без ручной загрузки модуля "loop"

См. Bug #661715. With SysV init, the loop module was unconditionally loaded by /etc/init.d/boot.localfs which is not used anymore. Для активации автоматичекской загрузки этого модуля выполните:

echo loop > /etc/modules-load.d/loop.conf

Отладка в systemd

To get debug from systemd, you can either :

remove quiet from kernel command line
increase systemd verbosity by adding debug to kernel command line. You can also add systemd.sysv_console=1 (0: disabled, 1: enabled) to display legacy SysV initscripts output on console.
modify /etc/systemd/system.conf (check man systemd.conf) to increase verbosity like this :

LogLevel=debug
LogTarget=syslog-or-kmsg
SysVConsole=yes

serial console isn't working

By default, systemd starts a minimal set of getty to let the system accessible.

When specifying on kernel command line which serial console should be used, only the last one in the list (which define the "active" console), will get a getty started :

console=tty0 console=ttyS0 will start a console on both tty0 (ie physical console) and serial console
console=ttyS0 console=tty0 will only start a console on tty0

Выполните для принудительного запуска консоли на последовательном порту:

ln -s /usr/lib/systemd/system/serial-getty@.service /etc/systemd/system/getty.target.wants/serial-getty@ttyS0.service

Отладка

Диагностика проблем загрузки

Если Ваша система при загрузке зависает, то сначала проверьте, проблема возникает до или после того, как управление предается systemd. Попробуйте загрузиться, удалив quiet в командной строке ядра. Это можно сделать в то время, когда отображается заставка меню grub: Esc → e → Выберите строку "kernel" → e → Удалите quiet и приведите к виду фрагмент "splash=verbose" → Enter → b.

Если при загрузке Вы увидите строки, подобные этим:

Welcome to openSuSE VERSION (codename)!" 
Starting name... 
[ OK ] Started name.

значит systemd работает.

Если Вы не получили приглашение для входа, тогда попробуйте переключиться в другую виртуальную консоль с помощью комбинации клавиш Ctrl+Alt+F<цифра>.

Если же Вы не можете войти ни в одну из виртуальных консолей, тогда попробуйте войти через => 5 мин. Существует вероятность того, что проблемные службы будут остановлены после этого тайм-аута и загрузка продолжится.

Вывод информации на последовательной консоли

Если у Вас есть устройство, доступное через последовательную консоль, то для отладки загрузитесь со следующими параметрами:

systemd.log_level=debug systemd.log_target=console console=ttyS0, 38400

Загрузка в однопользовательский или аварийный режим

Чтобы загрузиться в режиме одного пользователя, Вам необходимо добавить в командной строке ядра systemd.unit=rescue.target или 1. Этот режим может быть полезен в том случае, если проблема возникает где-то после загрузки базовой система, во время загрузки служб. Если это так, то здесь Вы можете отключить проблемную службу. В случае, если Вы не можете загрузиться в режиме одного пользователя, попробуйте загрузиться в систему с минимальным окружением (аварийный режим).

Чтобы загрузиться в аварийный режим, добавьте в командной строке ядра systemd.unit=emergency.target или emergency. Заметьте, что перед редактированием файлов Вы должны смонтировать корневую файловую систему для записи:

mount -o remount,rw /

Если же Вы не может загрузиться в аварийном режиме, тогда загрузитесь прямо в оболочку (shell) с помощью init=/bin/sh. Это может быть необходимо в случае испорченных библиотек systemd поврежденной файловой системы. Возможно, Вам придется переустановить на рабочие версии таких пакетов.

Заблаговременная оболочка (shell)

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

Вы можете разрешить доступ к оболочке во время начальной стадии процесса загрузки. Это позволит Вам выполнить диагностику systemd, вопросов связанных с загрузкой, используя различные команды systemctl. Сохраните файл службы в /etc/systemd/system/debug-shell.service и замените: ExecStart=@sushell@ на ExecStart=/bin/bash. Включите службу:

# systemctl enable debug-shell.service

Версия дистрибутива openSUSE 12.3. Файл службы поставляется вместе с systemd.

После перезагрузки, во время начального этапа загрузки, когда появиться приветствие "Welcome to openSuSE VERSION (codename)!", Вы можете войти в сессию tty9, используя комбинации клавиш Ctrl+Alt+F9. Оболочка позволит Вам читать логи , проверять статус служб, искать зависшие службы (systemctl list-jobs) и т. д. Если же Вы не можете использовать systemctl, то включите службу вручную с помощью другой загруженной системы, например, Live CD:

cd $ПУТЬ_ДО_КОРНЕВОЙ_ФС/etc/systemd/system
mkdir -p sysinit.target.wants
ln -s /usr/lib/systemd/system/debug-shell.service sysinit.target.wants/

У Вас есть доступ к оболочке (shell)

Если systemd работает в той степени, что может предоставить Вам оболочку, то для того, чтобы извлечь полезную информацию для отладки, Вам необходимо добавить в командной строке ядра следующие параметры:

systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M

После загрузки оболочки сохраните буфер сообщений ядра в файл:

dmesg > dmesg.txt

Для проверки списка зависших служб, которые могут быть виновниками остановки процесса загрузки и завершения работы системы, выполните:

$ systemctl list-jobs

Диагностика проблемы Shutdown

Так же, как с проблемами загрузки, когда Вы сталкиваетесь с зависанием, убедитесь в том, что прошло не менее 5 мин., чтобы отличить постоянные зависания от поломки системы. После этого попробуйте, реагирует ли система на комбинацию клавиш Ctrl+Alt+Del. Если перезагрузка/выключение Вашей системы надолго зависает, то в качестве теста исправности ядра можно перезагрузить или выключить систему принудительно с помощью одной из следующих команд:

# sync && reboot -f
# sync && poweroff -f

Если ни одна из команд не работает, то это ошибка ядра, а не systemd.

Shutdown долго завершается

загрузитесь со следующими параметрами:

systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M

создайте скрипт debug.sh в /usr/lib/systemd/system-shutdown/ и сделайте его исполняемым chmod +x:

#!/bin/sh
mount -o remount,rw /
dmesg > /shutdown-log.txt
mount -o remount,ro /

перезагрузитесь

Посмотрите тайм-ауты записанные в файле shutdown-log.txt.

Shutdown никогда не завершается

Если перезагрузка/отключение не завершается, даже после ожидания нескольких минут, то для закрытия ведения лога, описанного выше, необходимо воспользоваться одним из двух нижеприведенных методов:

использовать последовательную консоль
использовать заблаговременную оболочку - она остается активной до конца завершения работы.

Файл конфигурации systemd

При запуске системы, systemd считывает файл конфигурации system.conf, в противном случае user.conf. Эти конфигурационные файлы содержат несколько параметров управления возможностями менеджера. Далее будут приводиться только некоторые из них, параметры, касаемые отладки systemd.

Для увеличения детализации сообщений systemd необходимо раскомментировать следующие строки файла /etc/systemd/system.conf:

LogLevel=debug
LogTarget=syslog-or-kmsg
SysVConsole=yes

где LogLevel= уровень подробностей журнала; LogTarget= цель журнала, согласно переменной, например, kmsg — сообщения на уровне ядра (dmesg); SysVConsole= логический аргумент, отвечающий за вывод информации SysV сценарий направленных в консоль (по умолчанию true, если в командной строке ядра передается quiet, то по умолчанию будет false).

Подробности о возможных аргументах Вы можете узнать из страницы руководства man systemd.

Источники