systemd (Русский)

Ссылки по теме

• Systemd/Пользователь
• Systemd/Tаймеры
• Systemd/Журнал
• systemd FAQ
• init
• Демоны
• udev (Русский)
• Увеличение производительности/Процесс загрузки системы
• Разрешить пользователям выключение системы

Состояние перевода: На этой странице представлен перевод статьи systemd. Дата последней синхронизации: 31 октября 2019. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

Цитата с веб-страницы проекта:

systemd — это набор базовых строительных кирпичиков для системы Linux. Он предоставляет диспетчер системы и служб, который выполняется с PID 1 и запускает остальную часть системы. systemd обеспечивает возможности агрессивной параллелизации, использует сокеты и активацию D-Bus для запускаемых служб, предлагает запуск демонов по необходимости, отслеживает процессы при помощи контрольных групп Linux, поддерживает монтирование и точки монтирования, а также внедряет основанную на зависимостях логику контроля процессов сложных транзакций. systemd поддерживает сценарии инициализации SysV и LSB и является заменой sysvinit. Другие части включают в себя демон ведения журнала, утилиты для управления базовой конфигурацией системы (имя хоста, дата, языковой стандарт), ведение списка вошедших в систему пользователей, запущенных контейнеров и виртуальных машин, системных учётных записей, каталогов и параметров среды выполнения и демонов для управления базовой конфигурацией сети, синхронизации сетевого времени, пересылки журналов и разрешения имён.

Примечание: Смотрите сообщение на форуме для получения детальной информации о причинах перехода Arch на systemd.

Основы использования systemctl

Главная команда для отслеживания и контроля состояния systemd - команда systemctl. Некоторые из вариантов ее использования связаны с изучением состояния системы и управлением системой и службами. Обратитесь к странице руководства systemctl(1) для получения более детальной информации.

Совет:

• Вы можете использовать все приведенные ниже команды systemctl с ключом -H пользователь@хост, чтобы контролировать systemd на удаленной машине. В этом случае для соединения с удаленным процессом systemd будет использоваться SSH.

• systemadm - официальная графическая оболочка для systemctl. Она доступна в пакете systemd-ui.

• Пользователи Plasma могут использовать графический интерфейс systemd-kcm^AUR.

Анализ состояния системы

Показать состояние системы:

$ systemctl status

Список запущенных юнитов:

$ systemctl

или:

$ systemctl list-units

Список неудач — список юнитов, запуск которых не удался:

$ systemctl --failed

Доступные файлы юнитов можно посмотреть в каталогах /usr/lib/systemd/system/ и /etc/systemd/system/ (второй каталог имеет приоритет). Посмотреть список установленных файлов юнитов можно с помощью команды:

$ systemctl list-unit-files

Show the cgroup slice, memory and parent for a PID:

$ systemctl status pid

Использование юнитов

Юнитами могут быть, например, службы (.service), точки монтирования (.mount), устройства (.device) или сокеты (.socket).

При использовании systemctl обычно нужно указывать полное имя файла юнита, включая суффикс, например sshd.socket. Но есть несколько сокращений для указания юнита в следующих командах systemctl:

• Ели вы не указали суффикс, systemctl предполагает, что это .service. Например, netctl и netctl.service будут трактоваться одинаково
• Точки монтирования будут автоматически преобразованы в соответствующий юнит .mount. Например, указание /home равнозначно home.mount
• Как и точки монтирования, имена устройств автоматически преобразуются в соответствующий юнит .device, поэтому указание /dev/sda2 соответствует юниту dev-sda2.device

Для получения дополнительной информации смотрите страницу справочного руководства systemd.unit(5).

Примечание: В некоторых именах юнитов содержится знак @ (например, имя@строка.service). Это означает, что они являются экземплярами юнита-шаблона, в имени которого нет части строка (например, имя@.service). Часть строка называется идентификатором экземпляра и является аргументом, передаваемым юниту-шаблону при вызове команды systemctl: в файле юнита он заменит указание (specifier) %i.

Для большей точности работы systemd будет сперва искать юнит по полному имени файла имя@строка.суффикс, и лишь затем пытаться использовать экземпляр юнита-шаблона имя@.суффикс, даже несмотря на то, что подобные «конфликты» довольно редки, так как большинство файлов юнитов, содержащих знак @, подразумевают использование шаблонов. Также помните, что вызвать юнит-шаблон без идентификатора экземпляра не получится, поскольку в этом случае не будет возможности передать указание %i

Совет:

• Большинство указанных ниже команд также работают, если указать несколько юнитов. Для получения дополнительной информации смотрите страницу справочного руководства systemctl(1)
• С версии systemd 220 опция --now может быть использована в сочетании с enable, disable и mask, чтобы соответственно запустить, остановить или маскировать указанный юнит сразу при выполнении команды, а не после перезагрузки.
• Пакеты могут содержать юниты для различных целей. Если вы только что установили пакет, воспользуйтесь командой pacman -Qql package | grep -Fe .service -e .socket для проверки и нахождения юнитов.

Незамедлительно запустить юнит:

# systemctl start юнит

Незамедлительно остановить юнит:

# systemctl stop юнит

Перезапустить юнит:

# systemctl restart юнит

Попросить юнита перезагрузить его настройки:

# systemctl reload юнит

Показать статус юнита, а также запущен он или нет:

$ systemctl status юнит

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

$ systemctl is-enabled юнит

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

# systemctl enable юнит

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

# systemctl enable --now юнит

Убрать юнит из автозапуска при загрузке системы:

# systemctl disable юнит

Маскировать юнит, чтобы сделать невозможным его запуск (как вручную, так и в качестве зависимости, что делает маскировку несколько опасной):

# systemctl mask юнит 

Снять маскировку юнита:

# systemctl unmask юнит 

Показать страницу справочного руководства, связанного с юнитом (необходима поддержка этой функции в указанном файле юнита):

$ systemctl help юнит

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

Примечание: Эта команда перезагружает только настройки systemd и не просит юниты перезагрузить их собственные настройки; для юнитов используйте reload.

# systemctl daemon-reload

Управление питанием

Для управления питанием от имени непривилегированного пользователя необходим polkit. Если вы находитесь в локальной пользовательской сессии systemd-logind и нет других активных сессий, приведенные ниже команды сработают и без root. В противном случае (например, если другой пользователь вошел в систему в tty), systemd автоматически запросит у вас пароль суперпользователя.

Завершить работу и перезагрузить систему:

$ reboot

Завершить работу и выключить компьютер (с отключением питания):

$ poweroff

Перевести систему в ждущий режим:

$ systemctl suspend

Перевести систему в спящий режим:

$ systemctl hibernate

Перевести систему в режим гибридного сна (или suspend-to-both):

$ systemctl hybrid-sleep

Написание файлов юнитов

Синтаксис файлов юнитов systemd вдохновлен файлами .desktop XDG Desktop Entry Specification, а они, в свою очередь - файлами .ini Microsoft Windows. Файлы юнитов загружаются из многих мест (чтобы увидеть полный список, запустите systemctl show --property=UnitPath), но основные места — эти (чем ниже по списку, тем приоритетнее):

• /usr/lib/systemd/system/: юниты, предоставляемые пакетами при их установке;
• /etc/systemd/system/: юниты, устанавливаемые системным администратором.

Примечание:

• При запуске systemd в пользовательском режиме используются совершенно другие пути загрузки.
• Имена юнитов systemd могут содержать только буквы и цифры ASCII, нижнее подчёркивание и точки. Другие символы должны быть экранированы в C-стиле "\x2d" или использовать их предопределённую семантику ('@', '-'). Подробнее см. systemd.unit(5) и systemd-escape(1).

Для примера вы можете посмотреть юниты, предоставленные установленными пакетами, а также секцию примеров из systemd.service(5).

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

Обработка зависимостей

В случае использования systemd зависимости могут быть указаны правильным построением файлов юнитов. Типичный случай — юниту A требуется, чтобы юнит B был запущен перед тем, как запустится сам юнит A. В этом случае добавьте строки Requires=B и After=B в секцию [Unit] юнит-файла A. Если подобная зависимость не является обязательной, вместо этих строк укажите Wants=B и After=B соответственно. Обратите внимание, что Wants= и Requires= не подразумевают After=, что означает, что если After= не определено, то два юнита будут запущены параллельно друг другу.

Обычно зависимости указываются в файлах служб, а не в целевых (.target) юнитах. Например, network.target потребуется любой службе, которая связана с настройкой ваших сетевых интерфейсов, поэтому в любом случае определите загрузку вашего пользовательского юнита после запуска network.target.

Типы служб

Есть несколько типов запуска служб, которые нужно иметь в виду при написании файла службы. Тип определяется параметром Type= в секции [Service]:

• Type=simple (по умолчанию): systemd считает, что служба будет запущена незамедлительно. Процесс при этом не должен разветвляться (fork). Не используйте этот тип, если другие службы зависят от очередности при запуске данной службы. Исключение — активация сокета.
• Type=forking: systemd считает службу запущенной после того, как процесс разветвляется с завершением родительского процесса. Используйте данный тип для запуска классических демонов за исключением тех случаев, когда, как вам известно, в таком поведении процесса нет необходимости. Вам следует также определить PIDFile=, чтобы systemd могла отслеживать основной процесс.
• Type=oneshot: полезен для скриптов, которые выполняют одно задание и завершаются. Вам может понадобиться также установить параметр RemainAfterExit=yes, чтобы systemd считала процесс активным даже после его завершения.
• Type=notify: идентичен параметру Type=simple, но с той оговоркой, что демон пошлет systemd сигнал о своей готовности. Эталонная реализация данного уведомления представлена в libsystemd-daemon.so.
• Type=dbus: сервис считается находящимся в состоянии готовности, когда определенное BusName появляется в системной шине DBus.
• Type=idle: systemd will delay execution of the service binary until all jobs are dispatched. В остальном поведение аналогично Type=simple.

Смотрите справочную страницу руководства systemd.service(5) для более детального пояснения значений Type.

Редактирование предоставленных пакетами файлов юнитов

Не стоит редактировать юнит-файлы пакетов напрямую, так как это приведёт к конфликтам с pacman. Есть два безопасных способа редактирования юнит-файлов, предоставленных пакетом: создать новый файл, который полностью заменит оригинальный, или создать фрагмент кода, который применяется поверх оригинального файла из пакета. В обоих методах, чтобы применить изменения, нужно перезагрузить юнит. Это может быть сделано либо путем редактирования блока с помощью systemctl edit (которая автоматически перезагрузит юнит) либо перезагрузкой всех юнитов с помощью команды:

# systemctl daemon-reload

Совет:

• Вы можете использовать systemd-delta, чтобы увидеть, какие файлы юнитов были переопределены и что конкретно было изменено. Для обслуживания системы в целом важно регулярно проверять предоставляемые файлы юнитов на полученные обновления.
• Используйте systemctl cat юнит чтобы посмотреть содержимое файла юнита и все Drop-in snippets кода.
• Подсветку синтаксиса для файлов юнитов systemd в редакторе Vim можно включить, установив пакет vim-systemd^AUR из официальных репозиториев.

Замена файлов юнита

Чтобы полностью заменить файл юнита /usr/lib/systemd/system/юнит, создайте файл с таким же именем /etc/systemd/system/юнит и перезапустите юнит для обновления символьных ссылок:

# systemctl reenable юнит

В качестве альтернативы, можно выполнить:

# systemctl edit --full юнит

Эта команда откроет /etc/systemd/system/юнит в вашем текстовом редакторе (если файл ещё не существует, будет скопирован оригинальный файл из пакета в качестве основы) и автоматически перезагрузит его, когда вы закончите редактирование.

Примечание: Pacman не обновит заменённые файлы юнита, в отличие от оригинальных, которые обновятся. Так что этот метод может сделать обслуживание системы более сложным. По этой причине рекомендуется следующий подход.

Drop-in файлы

Чтобы создать drop-in файл для /usr/lib/systemd/system/юнит, создайте каталог /etc/systemd/system/юнит.d/ и поместите файлы .conf в нём, чтобы добавлять или заменять опции. systemd будет анализировать эти файлы .conf и применять их поверх оригинального юнита.

Самый простой способ сделать это — использовать команду:

# systemctl edit юнит

Она откроет /etc/systemd/system/юнит.d/override.conf в вашем текстовом редакторе (файл будет создан, если его ещё нет) и автоматически перезапустит юнит, когда вы закончите редактирование.

Примечание: Не все опции могут быть заменены в drop-in файле. Например, для изменения опции Conflicts= понадобится создать полную замену, как описано выше.

Возвращение оригинальной версии

Чтобы отменить все изменения, сделанные с помощью systemctl edit, воспользуйтесь командой:

# systemctl revert юнит

Примеры

Например, если вы просто хотите добавить дополнительную зависимость к юниту, можно создать следующий файл:

/etc/systemd/system/юнит.d/customdependency.conf

[Unit]
Requires=новая зависимость
After=новая зависимость

Другой пример: для замены ExecStart в юните (кроме типа oneshot) создайте следующий файл:

/etc/systemd/system/юнит.d/customexec.conf

[Service]
ExecStart=
ExecStart=новая команда

Обратите внимание, что ExecStart нужно очистить перед прописыванием нового значения ([1]). Это относится ко всем опциям, которые позволяют прописать несколько значений, например OnCalendar в таймерах.

Ещё пример для автоматического перезапуска службы:

/etc/systemd/system/юнит.d/restart.conf

[Service]
Restart=always
RestartSec=30

Цели

systemd использует цели (англ. target) для группировки юнитов по зависимостям и в качестве стандартизированных точек синхронизации. Они выполняют ту же задачу, что и уровни запуска (англ. runlevel), но действуют немного по-другому. Каждая цель имеет имя, а не номер, и, предназначена для конкретных задач; несколько целей могут быть активны одновременно. Некоторые цели реализованы путём наследования служб из других целей с добавлением своих служб. В systemd также имеются цели, имитирующие общие уровни запуска SystemVinit, поэтому вы можете переключаться между целями, используя привычную команду telinit RUNLEVEL.

Получение информации о текущих целях

При использовании systemd для этого предназначена следующая команда (заменяющая runlevel):

$ systemctl list-units --type=target

Создание пользовательской цели

Уровни запуска, имеющие определённое значение в sysvinit (0, 1, 3, 5 и 6), один в один соответствуют конкретным целям systemd. К сожалению, не существует хорошего способа сделать то же самое для пользовательских уровней, таких как 2 и 4. Их использование предполагает, что вы создаете новый именованный целевой юнит systemd наподобие /etc/systemd/system/ваша цель, который берет за основу один из существующих уровней запуска (взгляните, например, на /usr/lib/systemd/system/graphical.target), создаете каталог /etc/systemd/system/ваша цель.wants, а после этого - символические ссылки на дополнительные службы из каталога /usr/lib/systemd/system/, которые вы хотите включить при загрузке.

Соответствие уровней SysV целям systemd

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

Изменение текущей цели

В systemd цели доступны посредством целевых юнитов. Вы можете переключать их такой командой:

# systemctl isolate graphical.target

Данная команда только изменит текущую цель и не повлияет на следующую загрузку системы. Она соответствует командам Sysvinit вида telinit 3 и telinit 5.

Изменение цели загрузки по умолчанию

Стандартная цель — default.target, которая по умолчанию ссылается на graphical.target (примерно соответствующего прежнему уровню запуска 5).

Узнать текущую цель можно так:

$ systemctl get-default

Для установки новой цели загрузки по умолчанию измените ссылку default.target. С помощью команды systemctl это делается так:

# systemctl set-default multi-user.target

Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target.

Альтернативный способ — добавить один из следующих параметров ядра в ваш загрузчик:

• systemd.unit=multi-user.target (что примерно соответствует прежнему уровню запуска 3)
• systemd.unit=rescue.target (что примерно соответствует прежнему уровню запуска 1)

Порядок выбора цели по умолчанию

systemd выбирает default.target в таком порядке (чем выше по списку, тем приоритетнее):

1. Параметр ядра, показанный выше
2. Символьная ссылка /etc/systemd/system/default.target
3. Символьная ссылка /usr/lib/systemd/system/default.target

Временные файлы

"systemd-tmpfiles создает, удаляет и очищает непостоянные и временные файлы и каталоги". Он читает конфигурационные файлы из /etc/tmpfiles.d/ и /usr/lib/tmpfiles.d/, чтобы понять, что ему следует делать. Конфигурационные файлы в первом каталоге имеют приоритет над теми, что расположены во втором.

Конфигурационные файлы обычно предоставляются вместе с файлами служб и имеют названия вида /usr/lib/tmpfiles.d/программа.conf. Например, демон Samba предполагает, что существует каталог /run/samba с корректными правами доступа. Поэтому пакет samba поставляется в следующей конфигурации:

/usr/lib/tmpfiles.d/samba.conf

D /run/samba 0755 root root

Конфигурационные файлы также могут использоваться для записи значений при старте системы. Например, если вы используете /etc/rc.local для отключения пробуждения от устройств USB при помощи echo USBE > /proc/acpi/wakeup, вместо этого вы можете использовать следующий tmpfile:

/etc/tmpfiles.d/disable-usb-wake.conf

#    Path                  Mode UID  GID  Age Argument
w    /proc/acpi/wakeup     -    -    -    -   USBE

Для получения дополнительной информации смотрите страницы справочного руководства (man) systemd-tmpfiles(8) и tmpfiles.d(5).

Примечание: Этот способ может не сработать для установки опций в /sys, поскольку служба systemd-tmpfiles-setup может запуститься до того, как будут загружены соответствующие модули устройств. В этом случае при помощи команды modinfo модуль вы можете проверить, имеет ли модуль параметр для установки необходимой вам опции, и установить эту опцию в конфигурационном файле /etc/modprobe.d. В противном случае для установки верных атрибутов сразу, как только устройство появляется, вам придется написать правило udev

Таймеры

Таймер - это файл конфигурации юнита, имя которого заканчивается на .timer. Он содержит информацию о таймере, контролируемом при помощи systemd, для активации в определенное время. Смотрите статью systemd/Tаймеры.

Примечание: Таймеры способны в значительной степени заменить функциональность cron. Смотрите раздел Замена cron

Монтирование

Так как systemd полностью заменяет собой SysVinit, он отвечает за точки монтирования, описанные в файле /etc/fstab. systemd-fstab-generator(8) преобразует записи из /etc/fstab в юниты systemd; это выполняется при каждой загрузке системы, а также при перезагрузке конфигурации системного менеджера.

systemd расширяет возможности fstab и предлагает дополнительные опции монтирования. Они могут влиять на зависимости юнита монтирования: например, могут гарантировать, что монтирование выполняется только после подключения к сети или после монтирования другого раздела. Полный список опций монтирования systemd (обычно имеют префикс x-systemd), описан в systemd.mount(5).

Примером этих опций может быть т.н. автомонтирование (монтирование по запросу) (см. для более подробной информации как это реализовано).

Автомонтирование разделов GPT

На дисках GPT systemd-gpt-auto-generator(8) будет автоматически монтировать разделы в соответствии Discoverable Partitions Specification, так что они могут отсутствовать в fstab.

Автомонтирование раздела может быть отключено путём изменения GUID типа раздела или установкой атрибута 63 "do not automount"; см. gdisk#Prevent GPT partition automounting.

Советы и рекомендации

Запуск сервисов после подключения к сети

Чтобы запустить сервис только после подключения к сети, добавьте такие зависимости в .service файле:

/etc/systemd/system/foo.service

[Unit]
...
Wants=network-online.target
After=network-online.target
...

Также должна быть включена служба ожидания сети того приложения, которое управляет сетью; только тогда network-online.target будет соответствовать состоянию сети.

• В NetworkManager служба NetworkManager-wait-online.service включается вместе с NetworkManager.service. Проверить состояние службы можно командой systemctl is-enabled NetworkManager-wait-online.service. Если служба не включена, то включите NetworkManager.service ещё раз.
• В случае netctl включите службу netctl-wait-online.service.
• Для пользователей systemd-networkd юнит systemd-networkd-wait-online.service включается вместе со службой systemd-networkd.service; проверьте это командой systemctl is-enabled systemd-networkd-wait-online.service.

Подробнее можно почитать в systemd wiki: Running services after the network is up.

Включение установленных юнитов по умолчанию

Arch Linux поставляется с файлом /usr/lib/systemd/system-preset/99-default.preset, содержащим disable *. Это приводит к тому, что systemctl preset не включает юниты по умолчанию, так что после установки нового пакета пользователь должен сам включить его юниты.

Если такое поведение не устраивает, создайте символьную ссылку /etc/systemd/system-preset/99-default.preset на /dev/null для переопределения файла конфигурации. This will cause systemctl preset to enable all units that get installed—regardless of unit type—unless specified in another file in one systemctl preset's configuration directories. User units are not affected. Для получения дополнительной информации смотрите systemd.preset(5).

Примечание: Включение всех юнитов по умолчанию может привести к проблемам для пакетов, содержащих взаимоисключающие юниты. systemctl preset is designed to be used by distributions and spins or system administrators. In the case where two conflicting units would be enabled, you should explicitly specify which one is to be disabled in a preset configuration file as specified in the manpage for systemd.preset.

Песочница для приложений

A unit file can be created as a sandbox to isolate applications and their processes within a hardened virtual environment. systemd leverages namespaces, white-/blacklisting of Capabilities, and control groups to container processes through an extensive execution environment configuration.

The enhancement of an existing systemd unit file with application sandboxing typically requires trial-and-error tests accompanied by the generous use of strace, stderr and journalctl error logging and output facilities. You may want to first search upstream documentation for already done tests to base trials on.

Some examples on how sandboxing with systemd can be deployed:

• CapabilityBoundingSet defines a whitelisted set of allowed capabilities, but may also be used to blacklist a specific capability for a unit.
  • The CAP_SYS_ADM capability, for example, which should be one of the goals of a secure sandbox: CapabilityBoundingSet=~ CAP_SYS_ADM

Решение проблем

Изучение ошибок systemd

В качестве примера мы изучим ошибки службы systemd-modules-load:

1. Давайте найдем службы systemd, которые не смогли запуститься:

$ systemctl --failed

systemd-modules-load.service   loaded failed failed  Load Kernel Modules

Как вариант, можно почитать лог ошибок systemd:

$ journalctl -fp err

2. Хорошо, мы обнаружили проблему в службе systemd-modules-load и хотим узнать больше:

$ systemctl status systemd-modules-load

systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
   Active: failed (Result: exit-code) since Sun 2013-08-25 11:48:13 MSK; 32s ago
     Docs: man:systemd-modules-load.service(8).
           man:modules-load.d(5)
  Process: 15630 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)

Если вы не увидите в списке Process ID, просто перезапустите службу при помощи команды systemctl restart systemd-modules-load

3. Теперь у нас есть id процесса (PID) для более детального изучения ошибки. Введём следующую команду с правильным Process ID (в данном примере это 15630):

$ journalctl _PID=15630

-- Logs begin at Sat 2013-05-25 10:31:12 MSK, end at Sun 2013-08-25 11:51:17 MSK. --
авг 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module 'blacklist usblp'
авг 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module 'install usblp /bin/false'

4. Мы видим, что некоторые конфигурационные файлы модулей ядра имеют неверные настройки. В этом случае взглянем на эти настройки в каталоге /etc/modules-load.d/:

$ ls -Al /etc/modules-load.d/

...
-rw-r--r--   1 root root    79  1. дек  2012 blacklist.conf
-rw-r--r--   1 root root     1  2. мар 14:30 encrypt.conf
-rw-r--r--   1 root root     3  5. дек  2012 printing.conf
-rw-r--r--   1 root root     6 14. июл 11:01 realtek.conf
-rw-r--r--   1 root root    65  2. июн 23:01 virtualbox.conf
...

5. Сообщение об ошибке Failed to find module 'blacklist usblp' должно относиться к неправильной настройке в файле blacklist.conf. Давайте закомментируем настройку, вставив символ # перед каждой опцией, найденной на шаге 3:

/etc/modules-load.d/blacklist.conf

# blacklist usblp
# install usblp /bin/false

6. Теперь попробуем запустить systemd-modules-load:

$ systemctl start systemd-modules-load

Если всё прошло успешно, ничего не отобразится. Если же вы видите какие-либо ошибки, вернитесь к шагу 3 и используйте новый PID для устранения оставшихся ошибок.

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

$ systemctl status systemd-modules-load

systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
   Active: active (exited) since Sun 2013-08-25 12:22:31 MSK; 34s ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
 Process: 19005 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)
авг 25 12:22:31 mypc systemd[1]: Started Load Kernel Modules.

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

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

Загрузитесь с этими параметрами ядра:

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

Дополнительная информация по отладке.

Диагностика проблем в работе определенной службы

Если какая-либо служба systemd ведет себя не так, как ожидается, и вы хотите получить дополнительную информацию о том, что происходит, присвойте переменной окружения SYSTEMD_LOG_LEVEL значение debug. Например, чтобы запустить демон systemd-networkd в режиме отладки:

Добавьте drop-in файл для службы:

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

Или, как вариант, пропишите переменную окружения вручную:

# systemctl stop systemd-networkd
# SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd

После этого следите за журналом службы с помощью опции -f/--follow.

Если вы знаете, что в дальнейшем вам по-прежнему будет нужна эта отладочная информация, добавьте переменную обычным способом.

Выключение/перезагрузка происходят ужасно долго

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

По-видимому, процессы с кратким сроком жизни не оставляют записей в логах

Если команда journalctl -u foounit не показывает вывода для службы с коротким сроком жизни, вместо нее обратитесь к PID. Например, если загрузка службы systemd-modules-load.service завершилась неудачно и команда systemctl status systemd-modules-load показывает, что она была запущена с PID 123, то вы сможете посмотреть вывод процесса в журнале под данным PID, то есть командой journalctl -b _PID=123. Такие поля метаданных для журнала, как _SYSTEMD_UNIT и _COMM, собираются асинхронно и зависят от директории /proc в случае с действующими процессами. Исправление этой ситуации требует внесения исправлений в ядро для обеспечения предоставления этих данных через сокет, наподобие SCM_CREDENTIALS. В общем, это баг. Имейте в виду, что быстро падающие службы могут ничего не отпечатать в журнале as per design of systemd.

Отключение журналирования аварийных дампов памяти приложений

Добавьте в файл /etc/systemd/coredump.conf такую строку:

Storage=none

и выполните:

# systemctl daemon-reload 

чтобы перезагрузить конфигурацию.

Сообщение об ошибке при перезагрузке или выключении

cgroup : option or name mismatch, new: 0x0 "", old: 0x4 "systemd"

Для получения объяснения смотрите эту ветку.

watchdog watchdog0: watchdog did not stop!

Для получения объяснения смотрите эту ветку.

Время загрузки системы увеличивается с течением времени

После использования systemd-analyze некоторое количество пользователей заметило, что их время загрузки значительно увеличилось по сравнению с тем, к чему они привыкли. После использования systemd-analyze blame NetworkManager тратил необычно большое количество времени на запуск.

Проблема некоторых пользователей была связана с тем, что /var/log/journal становился слишком большим. При этом также может уменьшаться скорость работы других команд, например, systemctl status или journalctl. Для решения проблемы можно удалить все файлы из каталога журнала (в идеале - сделав где-нибудь резервные копии, хотя бы временно) и затем установить предел размера файла журнала, как описано в Systemd/Журнал#Ограничение размера журнала.

systemd-tmpfiles-setup.service fails to start at boot

Начиная с версии Systemd 219, /usr/lib/tmpfiles.d/systemd.conf определяет атрибуты для каталогов ACL, в /var/log/journal и, следовательно, требует чтобы поддержка ACL была включена для файловой системы, где находится журнал.

Смотрите инструкцию Access Control Lists (Русский)#Включение ACL для включения ACL на файловой системе в которой /var/log/journal.

Версия systemd, отображаемая при загрузке, не совпадает с версией пакета

Вам нужно пересоздать initramfs, после чего версии должны совпасть.

Совет: Можно использовать pacman hook для автоматического пересоздания initramfs после каждого обновления systemd. См. эту тему форума и Pacman#Hooks.

Отключение emergency mode на удалённой машине

Вам может понадобиться отключить emergency mode на удалённой машине, например на виртуальных машинах Azure или Google Cloud. Это связано с тем, что в случае ухода системы в emergency mode она отключится от сети и лишит вас возможности подключения к ней.

# systemctl mask emergency.service
# systemctl mask emergency.target

Смотрите также

• Systemd для администраторов (Рус.)
• systemd для администраторов (PDF) - перевод цикла статей Леннарта Поттеринга (Lennart Poettering)
• Статья в Википедии
• Официальный веб-сайт (англ.)
  • Оптимизации systemd
  • systemd FAQ
  • systemd Советы и трюки
• Страницы справочных руководств (англ.)
• Другие дистрибутивы
  • Страница systemd в Gentoo Wiki
  • О systemd в Fedora Project (англ.)
  • Fedora Project - Отладка проблем systemd (англ.)
  • Шпаргалка Fedora по переходу с SysVinit на systemd
  • Страница systemd в Debian Wiki
• Блог Lennart'а (англ.), update 1, update 2, update 3, Why systemd?
• Emacs Syntax highlighting for Systemd files (англ.)
• часть 1 и часть 2 вводной статьи в журнале The H Open (англ.)