Difference between revisions of "Systemd (Русский)"
Line 580: | Line 580: | ||
{{Tip|Вы можете заглянуть вовнутрь пакета, содержащего стартовые скрипты демона, чтобы узнать имена его сервис-файла. К примеру: | {{Tip|Вы можете заглянуть вовнутрь пакета, содержащего стартовые скрипты демона, чтобы узнать имена его сервис-файла. К примеру: | ||
− | $ pacman -Ql cronie | + | $ pacman -Ql cronie |
− | cronie / | + | [...] |
− | cronie /usr/lib/systemd/system/cronie.service | + | cronie /etc/rc.d/crond #демон initscript, указываемый в массивеe DAEMONS (не используется при "чистой" настройке systemd) |
+ | [...] | ||
+ | cronie /usr/lib/systemd/system/cronie.service #Соответствующий сервис 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.".
Смотрите также статью в Википедии.
Contents
- 1 Что надо усвоить до начала миграции на данную систему
- 2 Установка
- 3 Родные системные файлы в systemd
- 3.1 Имя компьютера (hostname)
- 3.2 Консоль и раскладка клавиатуры
- 3.3 Локаль
- 3.4 Временная зона
- 3.5 Аппаратные часы
- 3.6 Подгружаемые модули ядра
- 3.7 Черный список модулей ядра
- 3.8 Временные файлы
- 3.9 Монтирование удаленных файловых систем
- 3.10 Управлением питанием ACPI при помощи systemd
- 3.11 Хуки спящего режима
- 3.12 Ждущий режим
- 3.13 Юнит
- 4 Команды systemd
- 5 Уровни запуска/target-юниты
- 6 Таблица уровней запуска и их аналогов в Systemd
- 7 Запуск окружения рабочего стола из systemd
- 8 Журнал systemd
- 9 Сеть
- 10 Интеграция с Arch
- 11 Написание пользовательского .service файла
- 12 Оптимизация
- 13 Устранение неполадок
- 14 Полезные ссылки
Что надо усвоить до начала миграции на данную систему
- Настоятельно рекомендуется перейти на новую конфигурацию initscripts, описанную в статье rc.conf. Сконфигурировав таким образом свою систему, вы проделаете бóльшую часть работы, необходимую для миграции на systemd.
- Почитайте про systemd на сайте разработчиков.
- Обратите внимание, что systemd имеет собственный журнал (journal), заменяющий syslog, хотя оба варианта ведения логов могут сосуществовать. Обратитесь к приведенному ниже разделу разделу, посвященному журналу.
- Хотя systemd вполне способна заменить определенную функциональность таких демонов, как cron, acpid или xinetd, но если вы не хотите, можете не отказываться от использования традиционных демонов.
Установка
systemd может быть установлен параллельно со стандартным пакетом инициализации initscripts, и между ними можно будет переключаться путем добавления/удаления параметров ядра init=/usr/lib/systemd/systemd
.
Смешанная установка systemd/sysvinit/initscripts
Возможно иметь в своей системе одновременно установленными systemd и sysvinit и использовать одну и те же конфигурационные файлы, что позволит вам свободно переключаться между ним туда и обратно:
- Откажитесь от устаревших форматов конфигурации initscripts (о них сообщается при загрузке системы) в пользу родных системных файлов systemd и перезагрузитесь для проверки работоспособности данных установок при использовании initscripts.
- Установите пакет systemd из официальных репозиториев.
- Добавьте запись
init=/usr/lib/systemd/systemd
к параметрам ядра в вашем загрузчике. - Перезагрузите систему.
Systemd запустит демоны, перечисленные в /etc/rc.conf
, выполнит /etc/rc.local
и /etc/rc.local.shutdown
соответственно при загрузке/выключении системы. Если поддержка совместимости с массивом DAEMONS в конфигурационном файле rc.conf
или же скриптов в rc.local
вам не нужна, соответствующие сервис-файлы могут быть заблокированы (замаскированы) для их отключения.
Смешанная установка systemd/initscripts
Возможно заменить sysvinit на systemd, но сохранить initscripts в случае использования некоторых скриптов rc scripts, для которых пока не имеется эквивалентов в systemd.
- Следуйте инструкциям для смешанной установки systemd/sysvinit/initscripts.
- Включите демоны, ранее перечисленные в
/etc/rc.conf
с помощью командыsystemctl enable daemonname.service
. Для переноса демонов из/etc/rc.conf
в разряд сервисов systemd, смотрите разделы: List of Daemons и Services. Демоны, для которых не имеется соответствующих сервис-файлов systemd, следует оставить в массиве DAEMONS, поскольку systemd запустит устаревшие скрипты rc. - Установите пакет systemd-sysvcompat. Данный пакет конфликтует с sysvinit и вам будет предложено удалить последний.
- Удалите запись
init=...
, поскольку/sbin/init
теперь является символической ссылкой на systemd. - Перезагрузите систему.
Единственная разница между этим вариантом и вариантом с сохранением sysvinit состоит в том, что все бинарные файлы sysvinit заменены символическими ссылками на systemctl. Тем не менее, функциональность должна остаться неизменной.
Чистая установка systemd
Напоследок, возможно вовсе удалить initscripts и sysvinit и использовать только лишь systemd.
- Следуйте инструкциям для смешанной установки systemd/initscripts.
- Убедитесь, что более не имеется каких-либо демонов для запуска из массива DAEMONS в конфигурационном файле
/etc/rc.conf
и оба файла/etc/rc.local
и/etc/rc.local.shutdown
пусты. - Удалите пакет initscripts из вашей системы.
Дополнительная информация
quiet
, вероятно, вам стоит удалить его для нескольких первых загрузок systemd, чтобы видеть возникающие во время загрузке проблемы.Родные системные файлы в 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.
systemd-194
использует шрифт ядра и раскладку по умолчанию (т.е. американскую английскую). Нет более необходимости (для тех, кто использует данную раскладку) иметь в конфигурационном файле строки KEYMAP=
и FONT=
с пустыми значениями.Локаль
Для получения подробной информации о вариантах настройки обратитесь к руководству man locale.conf
/etc/locale.conf
LANG=ru_RU.UTF-8
Дальнейшая информация содержится в статье Locale.
Временная зона
Для получения подробной информации о вариантах настройки обратитесь к руководству man 5 localtime
.
# ln -sf /usr/share/zoneinfo/America/Chicago /etc/localtime
/etc/timezone
объявлен устаревшим с выходом systemd-190
и может/должен быть удален.Аппаратные часы
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 приводит вашу систему в спящий режим, а затем, когда система пробуждается менеджером управлением питания, снова "усыпляет" ее.
Handle
значение ignore
, если вы хотите, чтобы события ACPI обрабатывались в случае использования GNOME, Xfce, acpid или других программ. Но на подходе новые версии, которые включат данную функциональность.Хуки спящего режима
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-gitAUR из AUR).
Обратитесь к страницам руководств для получения дальнейшей информации.
systemctl
с ключом -H <user>@<host>
для того, чтобы контролировать systemd на удаленной машине. В этом случае для соединения с удаленным процессом systemd будет использовать SSH.Анализ состояния системы
Список запущенных юнитов:
$ 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>
Install
, это обычно означает, что данные сервисы вызываются автоматически другими сервисами. Но если вам требуется установить их вручную, используйте следующую команду, заменив foo
именем вашего сервиса.
# 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
Уровнень запуска SysV | Systemd Target | Примечание |
---|---|---|
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 уровни запуска доступны посредством "target-юнитов". Вы можете изменить их командой:
# systemctl isolate graphical.target
Данная команда изменит только лишь текущий уровень запуска и не повлияет на следующую загрузку системы. Она соответствует командам наподобие telinit 3
или telinit 5
для Sysvinit.
Изменение уровня запуска по умолчанию/target-юнита для загрузки
Стандартный target-юнит - default.target
, который по умолчанию является псевдонимом юнита graphical.target
(примерно соответствующего прежнему уровню выполнения 5). Для изменения уровня выполнения, выполняемого при загрузке по умолчанию, добавьте следующий дополнительный параметр ядра в вашем загрузчике:
.target
можно опустить.-
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.
/etc/inittab
вообще не используется.Если вы отключали использование сочетания клавиш для перезагрузки системы 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
rc.conf
, а использует родные системные файлы systemd.Последуйте настройке конфигурационных файлов как показано в разделе Родные системные файлы в systemd. Каждый файл заменяет одну из секций в /etc/rc.conf
, как показано в данной таблице:
Настройка | Конфигурационный файл (файлы) | Устаревшая секция rc.conf |
---|---|---|
Имя компьютера (Hostname) | /etc/hostname
|
NETWORKING
|
Консоль и раскладка клавиатуры | /etc/vconsole.conf
|
LOCALIZATION
|
Локаль | /etc/locale.conf
|
LOCALIZATION
|
Временная зона | /etc/localtime
|
LOCALIZATION
|
Аппаратные часы | /etc/adjtime
|
LOCALIZATION
|
Модули ядра | /etc/modules-load.d/
|
HARDWARE
|
Для целей совместимости секция 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-delta
, чтобы увидеть, какие файлы юнитов были переопределены и что в точности было изменено.Подсветка синтаксиса файлов юнитов systemd в Vim
подсветка синтаксиса файлов юнитов для systemd в редакторе Vim может быть осуществлена путем установки пакета vim-systemdAUR из AUR.
Оптимизация
systemd-analyze
Systemd предоставляет инструмент под названием systemd-analyze
, позволяющий проанализировать процесс загрузки вашей системы, чтобы можно было увидеть, какие файлы юнитов тормозят загрузку. Соответственно, вы можете оптимизировать вашу систему. Для использования данного инструмента вам потребуется установить пакеты python2-dbus и python2-cairo.
Чтобы увидеть, сколько времени было потрачено на подготовку пространства ядра и пространства пользователя во время загрузки, просто выполните команду:
$ systemd-analyze
timestamp
в ваш массив HOOKS
из конфигурационного файла /etc/mkinitcpio.conf
и от суперпользователя root пересоберите ваш образ initramfs командой mkinitcpio -p linux
Чтобы увидеть список запускаемых файлов юнитов, отсортированный по потраченному каждым из них на загрузку времени, выполните команду:
$ systemd-analyze blame
Вы также можете создать файл SVG, показывающий процесс загрузки в графическом виде, наподобие Bootchart:
$ systemd-analyze plot > plot.svg
Включение bootchart в связке с systemd
Вы можете использовать версию bootchart для визуализации последовательности при загрузке системы. Из-за невозможности использовать стандартные установки bootchart (так как нельзя добавить в командную строку ядра вторую запись init), вам придется воспользоваться пакетом bootchart2AUR из 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
~/.bashrc
английскую версию данных сокращений, чтобы избежать проблем с командной оболочкой. Сокращение вывода
Измените параметр 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>
--with-session-tracking=systemd
в PKGBUILD.Устранение неполадок
Выключение/перезагрузка происходят ужасно долго
Если процесс выключения занимает очень долгое время (или, по-видимому, зависает), то, вероятно, виноват сервис, который не завершает свою работу. 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