systemd (Русский)

From ArchWiki
Jump to navigation Jump to search

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

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

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

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

Contents

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

Главная команда для мониторинга и управления systemd — systemctl. Некоторые из вариантов её использования связаны с изучением состояния системы и управлением системой и службами. Подробнее смотрите руководство systemctl(1).

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

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

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

$ systemctl status

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

$ systemctl

или: 

$ systemctl list-units

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

$ systemctl --failed

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

$ systemctl list-unit-files

Показать cgroup slice, занимаемую память и родителя процесса по его PID: 

$ systemctl status pid

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

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

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

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

Подробнее смотрите руководство systemd.unit(5).

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

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

Совет:
  • Большинство команд ниже также будут работать, если указать несколько юнитов, см. systemctl(1).
  • Опция --now может использоваться в командах enable, disable и mask, чтобы соответственно запустить, остановить или маскировать указанный юнит сразу при выполнении команды, а не после перезагрузки.
  • Пакеты могут содержать собственные юниты для различных целей. Если вы только что установили пакет, воспользуйтесь командой pacman -Qql название_пакета | 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 автоматически запросит у вас пароль суперпользователя.

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

$ systemctl reboot

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

$ systemctl 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 в пользовательском режиме используются совершенно другие пути загрузки.
  • Названия юнитов могут содержать только буквы и цифры 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 отложит выполнение двоичного файла службы до момента выполнения всех остальных задач. В остальном поведение аналогично Type=simple.

Подробнее о параметре Type смотрите systemd.service(5).

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

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

# systemctl daemon-reload
Совет:
  • Вы можете использовать systemd-delta, чтобы увидеть, какие файлы юнитов были переопределены и что конкретно было изменено.
  • Используйте systemctl cat юнит для посмотра содержимого файлов юнитов и связанных с ними drop-in сниппетов.

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

Чтобы полностью заменить файл юнита /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 будет анализировать эти файлы и применять их поверх оригинального юнита.

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

# 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) для группировки юнитов по зависимостям и в качестве стандартизированных точек синхронизации. Они выполняют ту же задачу, что и уровни запуска, но действуют немного по-другому. Каждая цель имеет имя, а не номер, и предназначена для конкретных задач; несколько целей могут быть активны одновременно. Некоторые цели реализованы путём наследования служб из других целей с добавлением собственных. В systemd также имеются цели, имитирующие общие уровни запуска SystemVinit, поэтому вы можете переключаться между целями, используя привычную команду telinit RUNLEVEL.

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

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

$ systemctl list-units --type=target

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

Уровни запуска, имеющие определённое значение в sysvinit (0, 1, 3, 5 и 6), один в один соответствуют конкретным целям systemd. К сожалению, не существует хорошего способа сделать то же самое для пользовательских уровней 2 и 4. Их использование предполагает, что вы создаёте новый юнит-цель с названием /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

Подробнее смотрите systemd-tmpfiles(8) и tmpfiles.d(5).

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

Таймеры

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

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

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

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

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

Примером этих опций может быть т.н. автомонтирование (здесь имеется в виду не автоматическое монтирование во время загрузки, а монтирование при появлении запроса от устройства). Подробнее смотрите fstab#Автоматическое монтирование с systemd.

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

Для дисков с GPT-разметкой утилита systemd-gpt-auto-generator(8) будет автоматически монтировать разделы в соответствии с Discoverable Partitions Specification, поэтому их можно не указывать в файле /etc/fstab.

Для автоматического монтирования EFI-раздела загрузчик должен задать EFI-переменную LoaderDevicePartUUID. На данный момент это делает только systemd-boot.

Для автомонтирования разделов /var и /var/tmp их PARTUUID должен совпадать с хэш-суммой SHA256 HMAC, вычисленной на основании UUID типа раздела. В качестве ключа хэша используется machine ID. Необходимый PARTUUID можно получить командой: 

$ systemd-id128 -u --app-specific=UUID_типа_раздела machine-id

Значение UUID_типа_раздела можно взять из Discoverable Partitions Specification.

Примечание: Утилита systemd-id128(1) считывает machine ID из файла /etc/machine-id, поэтому вычислить PARTUUID до установки системы невозможно.

Автомонтирование любого раздела можно отключить, если изменить его GUID-тип или задать параметр раздела "do not automount". Подробнее смотрите GPT fdisk#Prevent GPT partition automounting.

systemd-sysvcompat

Пакет systemd-sysvcompat (зависимость пакета base) содержит традиционный бинарный файл init. В системах под управлением systemd файл init представляет собой лишь символическую ссылку на исполняемый файл systemd.

Кроме того, в этом пакете находится 6 команд SysVinit — halt(8), poweroff(8), reboot(8), runlevel(8), shutdown(8) и telinit(8). Эти команды являются символическими ссылками на файл systemctl, и их действие обусловлено логикой systemd. В разделе #Управление питанием говорилось о командах halt, poweroff, reboot и shutdown, в разделе #Соответствие уровней SysV целям systemd — о runlevel и telinit.

В systemd-системах отказаться от совместимости с System V можно либо задав параметр загрузки init= (см. BBS#233387), либо с помощью собственных аргументов команды systemctl.

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

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

Чтобы запустить сервис только после подключения к сети, добавьте такие зависимости в .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.

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

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Как это работает для юнитов-экземпляров? (Discuss in Talk:Systemd (Русский)#)

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

Если такое поведение не устраивает, создайте символическую ссылку /etc/systemd/system-preset/99-default.preset на /dev/null для переопределения файла конфигурации. Это заставит systemctl preset включать юниты новых пакетов — вне зависимости от типа — кроме указанных в других файлах из каталога настроек systemctl preset. Пользовательских юнитов это не касается. Подробнее смотрите systemd.preset(5).

Примечание: Политика включения всех юнитов по умолчанию может привести к проблемам, если в установленном пакете находится несколько взаимоисключающих юнитов. В этом случае в файле preset-настроек придётся явно указать, какие юниты включаться не должны. Подробнее смотрите systemd.preset(5).

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

Юнит может быть использован в качестве песочницы для изоляции приложений и их процессов в виртуальном окружении. Systemd использует механизм namespaces, белые и чёрные списки capabilities, а также control groups для контейнеризации процессов при помощи настраиваемых окружений.

Добавление к существующему юниту systemd функциональности песочницы обычно происходит методом проб и ошибок вкупе с использованием различных инструментов логирования — strace, stderr и journalctl. В таких случаях имеет смысл предварительно поискать соответствующую документацию от разработчиков.

Рекомендации по созданию песочницы с помощью systemd:

  • Параметр CapabilityBoundingSet определяет список разрешённых capabilities, но с его помощью можно также и запрещать некоторые capabilities для определённого юнита.
    • Например, можно задать capability CAP_SYS_ADM, необходимую для создания безопасной песочницы: CapabilityBoundingSet=~ CAP_SYS_ADM

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

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

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

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

$ systemctl --state=failed
systemd-modules-load.service   loaded failed failed  Load Kernel Modules

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

$ journalctl --follow --priority=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/true'

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/true

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.

Таким образом, проблема возникла из-за ошибки в файле blacklist.conf. Подробнее смотрите modules-load.d(5) и Модуль ядра#Запрет загрузки.

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

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

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

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

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

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

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

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

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

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

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

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

Если команда 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. В общем, это баг. Имейте в виду, что быстро падающие службы могут не успеть оставить сообщения в журнале из-за особенностей systemd.

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

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

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

systemd-tmpfiles-setup.service не запускается во время загрузки

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

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

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

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

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

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

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

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

Retrieved from "https://wiki.archlinux.org/index.php?title=Systemd_(Русский)&oldid=603711#Использование_юнитов"