Difference between revisions of "Systemd (Русский)"

Revision as of 01:44, 22 October 2012

zh-CN:systemd Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary end Цитата с веб-страницы проекта:

"systemd - система [инициализации] и менеджер служб для Linux, совместимые со скриптами инициализации SysV и LSB. systemd обеспечивает возможности агрессивной параллелизации, использует сокеты и активацию D-Bus для запускаемых служб, предлагает запуск демонов по необходимости, отслеживает процессы при помощи контрольных групп Linux, поддерживает мгновенные снимки и восстановление состояния системы, монтирование и точки монтирования, а также внедряет основанную на зависимостях логику контроля процессов сложных транзакций. Эта система может выступать заменой sysvinit.".

Смотрите также статью в Википедии.

Что надо усвоить до начала миграции на данную систему

• Настоятельно рекомендуется перейти на новую конфигурацию initscripts, описанную в статье rc.conf. Сконфигурировав таким образом свою систему, вы проделаете бóльшую часть работы, необходимую для миграции на systemd.
• Почитайте про systemd на сайте разработчиков.
• Обратите внимание, что systemd имеет собственный журнал (journal), заменяющий syslog, хотя оба варианта ведения логов могут сосуществовать. Обратитесь к приведенному ниже разделу разделу, посвященному журналу.
• Хотя systemd вполне способна заменить определенную функциональность таких демонов, как cron, acpid или xinetd, но если вы не хотите, можете не отказываться от использования традиционных демонов.

Установка

systemd может быть установлен параллельно со стандартным пакетом инициализации initscripts, и между ними можно будет переключаться путем добавления/удаления параметров ядра init=/usr/lib/systemd/systemd.

Смешанная установка systemd/sysvinit/initscripts

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

1. Откажитесь от устаревших форматов конфигурации initscripts (о них сообщается при загрузке системы) в пользу родных системных файлов systemd и перезагрузитесь для проверки работоспособности данных установок при использовании initscripts.
2. Установите пакет systemd из официальных репозиториев.
3. Добавьте запись init=/usr/lib/systemd/systemd к параметрам ядра в вашем загрузчике.
4. Перезагрузите систему.

Systemd запустит демоны, перечисленные в /etc/rc.conf, выполнит /etc/rc.local и /etc/rc.local.shutdown соответственно при загрузке/выключении системы. Если поддержка совместимости с массивом DAEMONS в конфигурационном файле rc.conf или же скриптов в rc.local вам не нужна, соответствующие сервис-файлы могут быть заблокированы (замаскированы) для их отключения.

Смешанная установка systemd/initscripts

Возможно заменить sysvinit на systemd, но сохранить initscripts в случае использования некоторых скриптов rc scripts, для которых пока не имеется эквивалентов в systemd.

1. Следуйте инструкциям для смешанной установки systemd/sysvinit/initscripts.
2. Включите демоны, ранее перечисленные в /etc/rc.conf с помощью команды systemctl enable daemonname.service . Для переноса демонов из /etc/rc.conf в разряд сервисов systemd, смотрите разделы: List of Daemons и Services. Демоны, для которых не имеется соответствующих сервис-файлов systemd, следует оставить в массиве DAEMONS, поскольку systemd запустит устаревшие скрипты rc.
3. Установите пакет systemd-sysvcompat. Данный пакет конфликтует с sysvinit и вам будет предложено удалить последний.
4. Удалите запись init=..., поскольку /sbin/init теперь является символической ссылкой на systemd.
5. Перезагрузите систему.

Единственная разница между этим вариантом и вариантом с сохранением sysvinit состоит в том, что все бинарные файлы sysvinit заменены символическими ссылками на systemctl. Тем не менее, функциональность должна остаться неизменной.

Чистая установка systemd

Напоследок, возможно вовсе удалить initscripts и sysvinit и использовать только лишь systemd.

1. Следуйте инструкциям для смешанной установки systemd/initscripts.
2. Убедитесь, что более не имеется каких-либо демонов для запуска из массива DAEMONS в конфигурационном файле /etc/rc.conf и оба файла /etc/rc.local и /etc/rc.local.shutdown пусты.
3. Удалите пакет initscripts из вашей системы.

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

Родные системные файлы в systemd

systemd будет использовать /etc/rc.conf, если эти конфигурационные файлы отсутствуют. Обратите внимание, что такое использование может быть только временным решением. Настоятельно рекомендуется для любой системы использовать конфигурационные файлы systemd.

Имя компьютера (hostname)

/etc/hostname

myhostname

Консоль и раскладка клавиатуры

Файл /etc/vconsole.conf устанавливает настройки виртуальной консоли: раскладку клавиатуры и консольный шрифт.

/etc/vconsole.conf

KEYMAP=ru
FONT=cyr-sun16
FONT_MAP=

Для получения детальной информации обратитесь к разделам Console fonts and Keymap.

Локаль

Для получения подробной информации о вариантах настройки обратитесь к руководству man locale.conf

/etc/locale.conf

LANG=ru_RU.UTF-8

Дальнейшая информация содержится в статье Locale.

Временная зона

Для получения подробной информации о вариантах настройки обратитесь к руководству man 5 localtime.

# ln -sf /usr/share/zoneinfo/America/Chicago /etc/localtime

Аппаратные часы

Systemd будет использовать UTC для аппаратных часов, именно такой вариант рекомендуется. Настройка зимнего/летнего времени - неблагодарное занятие. Если переход на зимнее/летнее время происходит в тот момент, когда ваш компьютер выключен, то при следующей загрузке ваши часы будут показывать ошибочное время (здесь об этом чуть подробнее (англ.)). Последние версии ядра устанавливают системное время из RTC (часов реального времени) непосредственно во время загрузки без использования hwclock, при этом ядро всегда считает, что RTC выставлено по UTC. Это означает, что если RTC выставлено по местному времени (local time), системное время будет изначально установлено ошибочно и затем корректироваться вскоре после этого при каждой загрузке. Это является причиной некоторых досадных багов (идущие назад часы редко являются нужной вещью).

Причиной, позволяющей RTC быть выставленными по местному времени, является двойная загрузка системы с Windows, (которая использует localtime (англ.)). Windows воспринимает RTC, выставленные по UTC при помощи простого исправления реестра. Если вы столкнетесь с подобными проблемами при двойной загрузке с Windows, вы можете установить аппаратные часы на использование местного времени.

/etc/adjtime

0.0 0.0 0.0
0
LOCAL

Другие параметры по-прежнему нужны, но они игнорируются systemd.

Обычно рекомендуется запускать демон Network Time Protocol для поддержания синхронизации аппаратных часов с системным временем.

Подгружаемые модули ядра

systemd использует конфигурационные файлы из директории /etc/modules-load.d/ для определения модулей ядра, подгружаемых во время загрузки системы. Каждый из конфигурационных файлов имеет наименование вида /etc/modules-load.d/<program>.conf (где <program> - имя подгружаемого модуля). При этом игнорируются как пустые строки конфигурационных файлов, так и строки, у которых первым символом, отличным о пробела, является символ # и ;. Например:

/etc/modules-load.d/virtio-net.conf

# Load virtio-net.ko at boot
virtio-net

Также смотрите раздел Modprobe#Options.

Черный список модулей ядра

Добавление модулей в черный список работает также, как и в случае с initscripts, поскольку в действительности эта функция выполняется таким инструментом, как kmod. Обратитесь к разделу Module Blacklisting за более подробной информацией.

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

Systemd-tmpfiles использует конфигурационные файлы в директориях /usr/lib/tmpfiles.d/ и /etc/tmpfiles.d/ для определения действий с временными файлами и директориями (создание, очистка и удаление их), обычно расположенные в /run or /tmp. Каждый файл с настройками имеет название вида /etc/tmpfiles.d/<program>.conf. Данные конфигурационные файлы имеют приоритет по сравнению с любыми файлами с таким же названием, расположенными в директории /usr/lib/tmpfiles.d/.

Временные файлы tmpfiles обычно поставляются вместе с сервис-файлами для создания директорийк. которые, как ожидается, будут использоваться определенными демонами. Например, демон Samba предполагает наличие директории /var/run/samba с соответствующими правами доступа. В данном случае tmpfile выглядит следующим образом:

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

D /var/run/samba 0755 root root

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

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

w /proc/acpi/wakeup - - - - USBE

Метод с использованием tmpfiles в данном случае рекомендуется, поскольку systemd в действительности не поддерживает /etc/rc.local.

Обратитесь к руководству man tmpfiles.d за более подробной информацией.

Монтирование удаленных файловых систем

Systemd позволяет в автоматическом режиме добиться, что удаленные файловые системы наподобие NFS и Samba подключаются после поднятия сети. are only started after the network has been set up. Поэтому монтирование удаленных файловых систем, прописанных в /etc/fstab должно работать "из коробки".

Однако, по желанию вы можете использовать автомонтирование для монирования удаленных файловых систем, чтобы монтирование данных систем происходило только по мере доступа к ним. Кроме того, вы можете использовать параметр x-systemd.device-timeout=# в файле /etc/fstab для определения таймаута в том случае, кода сетевые ресурсы оказываются недоступны.

Обратитесь к руководству man systemd.mount для получения более подробной информации.

Управлением питанием ACPI при помощи systemd

Systemd обрабатывает некоторые события, связанные с ACPI, что настраивается при помощи параметров в конфигурационном файле /etc/systemd/logind.conf:

• HandlePowerKey: определяет действия системы при нажатии кнопки питания (вкл./выкл.).
• HandleSuspendKey: определяет действия системы при нажатии кнопки спящего режима.
• HandleHibernateKey: определяет действия системы при нажатии кнопки ждущего режимаs.
• HandleLidSwitch: определяет действия системы при закрытии крышки компьютера.

Для соответствующих действий могут использоваться значения ignore (пропустить), poweroff (отключить питание), reboot (перезагрузить), halt (выключить), suspend (включить спящий режим), hibernate (включить ждущий режим) или kexec (системный вызов позволяющий оперативно переключиться в другое ядро).

Если данные параметры не определены, по умолчанию systemd будет использовать следующие: HandlePowerKey=poweroff, HandleSuspendKey=suspend, HandleHibernateKey=hibernate, и HandleLidSwitch=suspend.

В системах без графического интерфейса или использующих простые оконные менеджеры наподобие like i3 или awesome, так можно заменить демон acpid, который обычно используется для реагирования на данные события ACPI.

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

Хуки спящего режима

Systemd в своих командах systemctl suspend или systemctl hibernate не использует pm-utils для "усыпления" машины, поэтому хуки pm-utils, включая любые пользовательские хуки не будут работать. Тем не менее, systemd предоставляет схожий механизм запуска пользовательских скриптов для данных событий. Systemd запускает все исполняемые файлы в директории /usr/lib/systemd/system-sleep/ и передает каждому из них два аргумента:

• Аргумент 1: или pre, или post, в зависимости от которых машина либо "уснет", либо будет "пробуждена";
• Аргумент 2: или suspend, или hibernate, в зависимости от того, что было вызвано.

В отличие от pm-utils, systemd запустит данные скрипты одновременно, а не один после другого.

Вывод вашего скрипта будет записан сервисом systemd-suspend.service или systemd-hibernate.service, поэтому вы вы можете увидеть данный выход в журнале.

Обратите внимание, что вместо использования скриптов вы также можете использовать специальные целевые юниты - sleep.target, suspend.target или hibernate.target для того, чтобы подключить к другим юнитам возможности перехода в спящий режима.

Обратитесь к руководствам man systemd.special и man systemd-sleep для получения дальнейшей информации.

Пример

/usr/lib/systemd/system-sleep/example.sh

#!/bin/sh
case $1/$2 in
  pre/*)
    echo "Going to $2..."
    ;;
  post/*)
    echo "Waking up from $2..."
    ;;
esac

Ждущий режим

Смотрите английскую версию вики.

Юнит

Юнит (англ. unit) - конфигурационный файл, содержащий информацию о сервисе (службе), сокете, устройстве, точке монирования/автомонирования, файле подкачке или разделе, определяемом для загрузки уровне запуска, пути в файловой системе или таймере, которые контролируются и управляются при помощи systemd. Синтаксис юнитов навеян спецификацией .desktop-файлов (XDG Desktop Entry Specification), которая, в свою очередь, вдохновлялась .ini-файлами от Microsoft Windows. Обратитесь к руководству man systemd.unit для получения дальнейшей информации.

Команды systemd

• systemctl: используется для наблюдения и контроля за состоянием менеджера системы и сервисов systemd.
• systemd-cgls: рекурсивно показывает содержимое иерархии избранной контрольной группы (cgroup) Linux в виде дерева.
• systemadm: графическая оболочка для менеджера системы и сервисов systemd , позволяющая наблюдать и контролировать systemd (доступна в виде пакета systemd-ui-git^AUR из AUR).

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

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

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

$ systemctl

или:

$ systemctl list-units

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

$ systemctl --failed

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

$ systemctl list-unit-files

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

Юниты могут быть сервисами (.service), точками монтирования (.mount) или сокетами (.sockets). При использовании команды systemctl необходимо всегда указывать полное имя файла, включая расширение. Однако, есть несколько сокращений при определении юнита следующими командамиsystemctl:

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

Обратитесь к руководству man systemd.unit для получения детальной информации.

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

# systemctl start <unit>

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

# systemctl stop <unit>

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

# systemctl restart <unit>

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

# systemctl reload <unit>

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

$ systemctl status <unit>

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

$ systemctl is-enabled <unit>

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

# systemctl enable <unit>

# ln -s /usr/lib/systemd/system/foo.service /etc/systemd/system/graphical.target.wants/

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

# systemctl disable <unit>}}

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

$ systemctl help <unit>

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

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

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

$ systemctl reboot

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

$ systemctl halt

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

$ systemctl suspend

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

$ systemctl hibernate

Уровни запуска/target-юниты

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

Получение информации о текущем уровне запуска/target-юнитах

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

# systemctl list-units --type=target

Создание пользовательского target-юнита

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

Таблица уровней запуска и их аналогов в Systemd

Изменение текущего уровня запуска

В systemd уровни запуска доступны посредством "target-юнитов". Вы можете изменить их командой:

# systemctl isolate graphical.target

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

Изменение уровня запуска по умолчанию/target-юнита для загрузки

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

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

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

# systemctl enable multi-user.target

Эффект от применения данной команды выводится через systemctl; символическая ссылка на новый target-юнит по умолчанию создается в директории /etc/systemd/system/default.target. Это сработает в том случае (и только в том случае), если имеется следующая секция:

[Install]
Alias=default.target

в конфигурационном файле target-юнита. В настоящий момент как multi-user.target, так и graphical.target оба имеют данную секцию.

Запуск окружения рабочего стола из systemd

Использование экранного менеджера

Чтобы ключить графический вход в систему, запустите выбранный вами демон экранного менеджера (например, KDM). В настоящий момент доступны сервис-файлы для GDM, KDM, SLiM, XDM, LXDM и LightDM.

# systemctl enable kdm.service

Эта команда должна работать "из коробки". Если вдруг она не сработала, то, возможно, у вас default.target установлен вручную или остался с прежней установки:

# ls -l /etc/systemd/system/default.target

/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target

Просто удалите символическую ссылку и systemd будет использовать целевой юнит по умолчанию - default.target (т.е. graphical.target).

# rm /etc/systemd/system/default.target

Запуск через файл сервиса

если вам нужен простой путь запуска X напрямую, без использования экранного менеджера входа в систему, вы можете создать сервис-файл наподобие приведенного ниже:

/etc/systemd/system/graphical.target.wants/xinit.service

[Unit]
Description=Direct login to X
After=systemd-user-sessions.service

[Service]
ExecStart=/bin/su <username> -l -c "/bin/bash --login -c xinit"

[Install]
WantedBy=graphical.target

Журнал systemd

С версии 38 systemd имеет собственную систему ведения логов - журнал (journal).

По умолчанию, более не требуется запуск демона syslog. Для чтения логов используйте команду:

# journalctl

Журнал записывается в директорию /run/systemd/journal, поэтому логи будут потеряны при перезагрузке. Для сохранения логов создайте директорию /var/log/journal/:

# mkdir /var/log/journal/

Фильтрация вывода

journalctl позволяет фильтровать вывод по особым полям.

Примеры:

Показать все сообщения определенной программы:

# journalctl /usr/lib/systemd/systemd

Показать все сообщения определенного процесса:

# journalctl _PID=1

Показать все сообщения определенного юнита:

# journalctl _SYSTEMD_UNIT=netcfg.service

Обратитесь к man journalctl и systemd.journal-fields для получения детальной информации.

Ограничение размера журнала

Если журнал сохраняется при перезагрузке, размер его по умолчанию ограничен значением в 10% от объема соответствующей файловой системы. Например, для директории /var/log/journal, расположенной на корневом разделе в 50 Гбайт, максимальный размер журналируемых данных составит до 5 Гбайт. Максимальный объем постоянного журнала можно контролировать при помощи значения SystemMaxUse в конфигурационном файле /etc/systemd/journald.conf, поэтому для ограничения его объемом в 50 Mбайт раскомментируйте и отредактируйте соответствующую строку:

SystemMaxUse=50M

Обратитесь к man journald.conf для получения дальнейшей информации.

Journald в связке с классическим демоном syslog

Совместимость с классической реализацией syslog обеспечивается сокетом /run/systemd/journal/syslog, в который перенаправляются все сообщения. Чтобы дать созможность демону syslog работать вместе с журналом systemd, следует привязать данный демон к указанному сокету вместо /dev/log (официальное сообщение). В случае с syslog-ng, измените раздел source src в конфигурационном файле /etc/syslog-ng/syslog-ng.conf по следующем образцу:

source src {
    unix-dgram("/run/systemd/journal/syslog");
    internal();
    file("/proc/kmsg");
};

и включите syslog-ng:

# systemctl enable syslog-ng.service

Сеть

Динамическое подключение (DHCP) с использованием dhcpcd

Если хотите использовать только DHCP для своего соединения Ethernet, вы можете воспользоваться сервисом dhcpcd@.service (который поставляется пакетом dhcpcd).

Чтобы подключить DHCP для eth0, просто выполните команду:

# systemctl start dhcpcd@eth0.service

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

# systemctl enable dhcpcd@eth0.service

Иногда сервис dhcpd запускается до загрузки модуля вашей сетевой карты (FS#30235), в этом случае вручную добавьте вашу сетевую карту в конфигурационный файл /etc/modules-load.d/*.conf. Например, для карты Realtek необходима загрузка модуля r8169, поэтому создайте такой конфигурационный файл:

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

r8169

Другие конфигурации

Для статического подключения, беспроводной сети или сложной конфигурации сети наподобие сетевого моста, вы можете использовать netcfg или NetworkManager, для обеих этих инструментов управления сетью имеются сервис-файлы для systemd.

Интеграция с Arch

Эмуляция initscripts

Интеграция с классической конфигурацией Arch Linux обеспечивается пакетом initscripts. Данная интеграция рассматривается как просто переходная мера для легкой миграции пользователей на systemd.

Если вы отключали использование сочетания клавиш для перезагрузки системы Template:Keypress в файле /etc/inittab, теперь вам надо заново сделать это для systemd командой systemctl mask ctrl-alt-del.target, выполняемой от суперпользователя root.

rc.conf

Некоторые переменные в прежнем основном конфигурационном файле /etc/rc.conf предположительно не будут корректно работать. Для чистой установки systemd setup рекомендуется использовать родные системные файлы, которые имеют приоритет над установками в /etc/rc.conf.

Поддерживаются (но не рекомендуются):

• CONSOLEFONT
• CONSOLEMAP
• DAEMONS
• HOSTNAME
• KEYMAP
• LOCALE

Не поддерживаются:

• HARDWARECLOCK: обратитесь к разделу Аппаратные часы.
• MODULES: используйте взамен конфигурационные файлы в директории modules-load.d.
• TIMEZONE: вручную сделайте символическую ссылку /etc/localtime на файл вашей временной зоны.
• USELVM: взамен используйте lvm.service, поставляемый пакетом lvm2.
• USECOLOR

Полный переход к конфигурационным файлам systemd

Последуйте настройке конфигурационных файлов как показано в разделе Родные системные файлы в systemd. Каждый файл заменяет одну из секций в /etc/rc.conf, как показано в данной таблице:

Для целей совместимости секция DAEMONS в /etc/rc.conf еще может использоваться вместе с systemd для запуска сервисов при загрузке системы, даже при "чистой" установке менеджера служб systemd. Взамен этого вы можете полностью удалить файл /etc/rc.conf и включить сервисы в systemd. Для каждого сервиса с именем <service_name> в массиве DAEMONS из файла /etc/rc.conf выполните команду:

# systemctl enable <service_name>.service

Если сервис-файл <service_name>.service отсутствует:

• сервис-файл может быть недоступен для systemd. В этом случае вам нужно сохранить конфигурационный файл rc.conf для запуска этих сервисов во время загрузки системы.
• systemd может называть сервисы другими именами, например, cronie.service заменяет демон crond; alsa-store.service и alsa-restore.service заменяют демон alsa. Другой важный пример - демон network, которого сменил целый набор сервис-файлов (обратитесь к разделу #Сеть для получения дальнейшей информации.)

$ pacman -Ql cronie
[...]
cronie /etc/rc.d/crond                            #демон initscript, указываемый в массивеe DAEMONS (не используется при "чистой" настройке systemd)
[...]
cronie /usr/lib/systemd/system/cronie.service     #Соответствующий сервис systemd
[...]

Написание пользовательского .service файла

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

В случае использования 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]. Обратитесь к руководству man systemd.service для получения более детального объяснения.

• Type=simple: systemd предполагает, что сервис будет запущен незамедлительно. Процесс при этом не должен форкнуться. Не используйте этот тип, если другим сервисы зависят от очередности при запуске данного сервиса, за исключением активации сокета.
• Type=forking: systemd предполагает, что сервис запускается однократно, процесс форкается и родительский процесс завершается. Используйте данный тип для запуска классических демонов за исключением тех случаев, когда, как вам известно, в таком поведении процесса нет необходимости. Вам следует также определить PIDFile=, чтобы systemd могла отслеживать основной процесс.
• Type=oneshot: Полезен для скриптов, которые выполняют одну работу, а потом завершаются. Вам может понадобиться также установить параметр RemainAfterExit=, чтобы systemd по-прежнему считала процесс активным, даже после его завершения
• Type=notify: Идентичен параметру Type=simple, но с той оговоркой, что демон пошлет systemd сигнал о своей готовности. Эталонная реализация данного уведомления обеспечивается библиотекой libsystemd-daemon.so.
• Type=dbus: Сервис считается находящимся в состоянии готовности, когда определенное BusName появляется в системной шине DBus.

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

Файлы юнитов в директории /etc/systemd/system/ имеют приоритет над такими же файлами в директории /usr/lib/systemd/system/. Для создания собственной версии юнита (который не будет затерт при обновлении), скопируйте старый юнит из директории /usr/lib/ в директорию /etc/ и внесите в эту копию свои изменения. Альтернативным вариантом является использование .include для парсинга существующего сервис-файла и затем переопределения или добавления новых опций. Например, если вы просто хотите добавить в сервис-файл дополнительную зависимость, вы можете использовать такую команду в юните:

/etc/systemd/system/<service-name>.service

.include /usr/lib/systemd/system/<service-name>.service

[Unit]
Requires=<new dependency>
After=<new dependency>

Затем выполните следующие команды для того, чтобы изменения вступили в силу:

# systemctl reenable <unit>
# systemctl restart <unit>

Подсветка синтаксиса файлов юнитов systemd в Vim

подсветка синтаксиса файлов юнитов для systemd в редакторе Vim может быть осуществлена путем установки пакета vim-systemd^AUR из AUR.

Оптимизация

systemd-analyze

Systemd предоставляет инструмент под названием systemd-analyze, позволяющий проанализировать процесс загрузки вашей системы, чтобы можно было увидеть, какие файлы юнитов тормозят загрузку. Соответственно, вы можете оптимизировать вашу систему. Для использования данного инструмента вам потребуется установить пакеты python2-dbus и python2-cairo.

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

$ systemd-analyze

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

$ systemd-analyze blame

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

$ systemd-analyze plot > plot.svg

Включение bootchart в связке с systemd

Вы можете использовать версию bootchart для визуализации последовательности при загрузке системы. Из-за невозможности использовать стандартные установки bootchart (так как нельзя добавить в командную строку ядра вторую запись init), вам придется воспользоваться пакетом bootchart2^AUR из AUR, поставляемым с недокументированным сервисом systemd. После установки bootchart2 выполните команду:

# systemctl enable bootchart.service

Обратитесь к документации bootchart (англ.) за дальнейшей и детализированной информацией об использовании данной версии bootchart.

Сокращения командной оболочки

Демон управления systemd требует ввода достаточно большого объема текста команд для выполнения таких процессов, как запуск, остано, включение, проверка статуса сервисов и т.д. Добавление в ваш конфигурационный файл ~/.bashrc следующих функций поможет уппростить взаимодействие с systemd и усовершенствовать опыт ее использования.

# упростим команду systemd, например, "sudo systemctl stop xxx.service" - > "0.stop xxx"
if ! systemd-notify --booted;
then  # for not systemd
    0.start() {
        sudo rc.d start $1
    }

    0.restart() {
        sudo rc.d restart $1
    }

    0.stop() {
        sudo rc.d stop $1
    }
else
# запустить сервис systemd
    0.start() {
        sudo systemctl start $1.service
    }
# перезапустить сервис systemd
    0.restart() {
        sudo systemctl restart $1.service
    }
# stop systemd service
    0.stop() {
        sudo systemctl stop $1.service
    }
# включить сервис systemd
    0.enable() {
        sudo systemctl enable $1.service
    }
# выключить сервис systemd
    0.disable() {
        sudo systemctl disable $1.service
    }
# показать статус сервиса
    0.status() {
        systemctl status $1.service
    }
# прерзагрузить конфигурацию сервиса
    0.reload() {
        sudo systemctl reload $1.service
    }
# показать все запущенные сервисы
    0.list() {
        systemctl
    }
# показать все сервисы, запуск которых завершился неудачей
    0.failed () {
        systemctl --failed
    }
# показать все доступные файлы юнитов
    0.list-files() {
        systemctl list-unit-files
    }
# проверить лог
    0.log() {
        sudo journalctl
    }
# показать необязательные зависимости
    0.wants() {
        systemctl show -p "Wants" $1.target
    }
# анализ системы
    0.analyze() {
        systemd-analyze $1
    }
fi

Сокращение вывода

Измените параметр verbose на quiet в строке загрузки ядра вашего загрузчика. Для некоторых систем, в частности с SSD, узким местом является низкая производительность TTY, поэтому сокращение вывода означает прирост скорости загрузки.

Ранний старт

Одним из центральных элементов systemd является D-Bus и активация сокетов, что требует запуска сервисов при первой потребности в них. Обычно такой подход является удачным, но, если вы знаете, что какой-то сервис (вроде ConsoleKit)должен всегда запускаться во время загрузки системы, то вы можете сократить общее время загрузки, запуская его так рано, как это вообще возможно. Этого можно добиться (если сервис-файл устроен соответствующим образом, что верно в большинстве случаев) путем выполнения команды:

# systemctl enable console-kit-daemon.service

Это заставит systemd запустить ConsoleKit как рано, как это возможно, не устраивая перегонки данного сервиса с активацией сокета или D-Bus.

Автомонитрование

Установка по умолчанию запускает fsck и монтирует все файловые системы перед запуском большинства демонов и сервисов. Если ваш раздел /home занимает большой объем, лучшим вариантом было бы позволить сервисам не зависеть от подключения /home и запускать данные сервисы, когда /home еще подвергается проверке при загрузке системы. Добиться такого результата можно добавлением следующих параметров в запись файла fstab, касающуюся раздела /home:

noauto,x-systemd.automount

Такие параметры вызовут fsck и примонтируют /home при первом обращении к данному разделу, и ядро будет буферизовать все файлы доступа к /home до готовности данного раздела.

В случае использования зашифрованных файловых систем с ключами доступа, вам также Iследует добавить параметр noauto в соответствующие записи файла /etc/crypttab. systemd не будет подключать зашифрованные устройства при загрузке, но, вместо этого, дождется реального обращения к ним и автоматически откроет к ним доступ с использованием определенных ключей перед тем, как они будут примонтированы. Это сэкономит несколько секунд при загрузке системы, например, в случае использования зашифрованного устройства RAID, потому что systemd не будет дожидаться от устройства, когда оно станет доступным. Например:

/etc/crypttab

data /dev/md0 /root/key noauto

Readahead

systemd поставляется со свой реализации технологии readahead, что в принципе должно усовершенствовать процесс загрузки системы. Однако, в зависимости от версии вашего ядра и типа жесткого диска, скорость обращения к данным может разниться (например, может быть медленнее). Чтобы включить данный сервис, выполните:

# systemctl enable systemd-readahead-collect.service systemd-readahead-replay.service

Не забудьте, что волшебство технологии readahead подействует только после нескольких перезапусков системы

Замена ConsoleKit на systemd-logind

Начиная с polkit 0.107 (в настоящее время в репозитории [testing]), ConsoleKit можно полностью заменить на systemd-logind. Самый легкий метод удаления ConsoleKit заключается в автоматическом входе в виртуальную консоль и запуска X оттуда. Важно понять, что, как указано в последней статье, сервер X запускается в той же виртуальной консоли, в которую вы загрузились, в противном случае systemd не сможет следить за пользовательской сессией. Затем можно просто удалить ck-launch-session из вашего файла ~/.xinitrc.

Для того, чтобы проверить статус вашей пользовательской сессии, вы можете использовать команду loginctl. Чтобы убедиться, что ваша пользовательская сессия правильно установлена, проверьте, содержит ли следующая команда Active=yes. Все действия polkit actions наподобие перевода системы в спящий режим или монтирования внешних носителей с помощью Udisks должны работать автоматически.

$ loginctl show-session <session-id>

Устранение неполадок

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

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

Полезные ссылки

• Официальный веб-сайт (англ.)
• Страницы руководств (англ.)
• systemd Optimizations (англ.)
• FAQ (англ.)
• Tips And Tricks (англ.)
• systemd для администраторов (PDF) - перевод цикла статей Леннарта Поттеринга (Lennart Poettering)
• Блог Lennart'а (англ.)
• systemd mini FAQ
• systemd - база знаний проекта Fedora
• Fedora Linux Wiki: Systemd (англ.)
• Debian Wiki: systemd - менеджер системы и сервисов
• Ubuntu Wiki: systemd (англ.)
• OpenSuse Wiki: SDB:Systemd