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

From ArchWiki
Jump to: navigation, search
m (Таблица target-юнитов)
m
Line 1: Line 1:
 
[[Category:Русский]]
 
[[Category:Русский]]
[[Category:Демоны и системные сервисы]]
+
[[Category:Демоны и системные сервисы (Русский)]]
[[Category:Процесс загрузки]]
+
[[Category:Процесс Загрузки (Русский)]]
 
[[en:systemd]]
 
[[en:systemd]]
 
[[es:systemd]]
 
[[es:systemd]]

Revision as of 09:18, 21 October 2012

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.".

Note: За детальным объяснением причин перехода Arch'а на systemd обратитесь к сообщению на англоязычном форуме.

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

Contents

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

  • Настоятельно рекомендуется перейти на новую конфигурацию 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 вам не нужна, соответствующие сервис-файлы могут быть заблокированы (замаскированы) для их отключения.

Warning: В случае, когда у вас в массиве DAEMONS перечислены демоны, для которых имеются родные сервис-файлы systemd, автоматически будут использоваться родные сервис-файлы. Тем не менее, если имена скриптов rc и сервисов systemd (так далее будут именоваться службы данной системы инициализации) не соответствуют друг другу, данное правило не сработает и вам следует убедиться, что только включен только один из них двух (предпочтительно родной сервис-файл).
Warning: Systemd - процесс асинхронной загрузки по сравнению сравнении с последовательным запуском демонов из массива DAEMONS. В частности, "network", будучи поддерживаемым для совместимости сервисом, может запуститься слишком поздно для включения интерфейсов, которые требуются другим сервисам. Рекомендуется переключиться на использование netcfg или NetworkManager до перехода на systemd.

Смешанная установка 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 из вашей системы.

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

Tip: Если в параметрах ядра имеется значение quiet, вероятно, вам стоит удалить его для нескольких первых загрузок systemd, чтобы видеть возникающие во время загрузке проблемы.

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

Note: Возможно, вам придется создать эти файлы. Установите для них права доступа 644 и владельца root:root.

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.

Note: 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
Note: Прежний конфигурационный файл /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 приводит вашу систему в спящий режим, а затем, когда система пробуждается менеджером управлением питания, снова "усыпляет" ее.

Note: В настоящее время менеджер управления питанием новейшей версии в KDE является единственным, который использует такие команды "подавления". До тех пор, пока их не будут применять другие менеджеры, вам надо выставить в параметрах 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).

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

Tip: Вы можете использовать приведенные ниже команды 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>
Note: Если сервис-файлы не имеют раздела 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). Для изменения уровня выполнения, выполняемого при загрузке по умолчанию, добавьте следующий дополнительный параметр ядра в вашем загрузчике:

Tip: Расширение .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

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

Note: При использовании данного метода для вашего пользователя не будет создана PAM-сессия, поэтому ConsoleKit (предоставляющий допуск к выключению/перезагрузке системы, аудиоустройствам и т.д.) не будет корректно работать. Рекомендуемый путь описан в разделах: Замена ConsoleKit на systemd-logind и Автоматический вход в виртуальную консоль с помощью systemd.

если вам нужен простой путь запуска 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.

Note: Если вы хотите использовать netcfg, networkmanager или другие программы управления сетью, вам не надо в этом случае запускать или включать сервис dhcpcd как показано в предыдущем параграфе.

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

Эмуляция initscripts

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

Note: Файл /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

Note: Этот метод является предпочтительным, при его использовании система более не зависит от централизованной настройки в файле rc.conf, а использует родные системные файлы systemd.

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

Настройка Конфигурационный файл (файлы) Устаревшая секция rc.conf
Имя компьютера (Hostname) /etc/hostname

/etc/hosts

NETWORKING
Консоль и раскладка клавиатуры /etc/vconsole.conf LOCALIZATION
Локаль /etc/locale.conf

/etc/locale.gen

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
Tip: Для получения списка обычно используемых демонов с их эквивалентами в initscripts и systemd, обратитесь к данной таблице.

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

  • сервис-файл может быть недоступен для systemd. В этом случае вам нужно сохранить конфигурационный файл rc.conf для запуска этих сервисов во время загрузки системы.
  • systemd может называть сервисы другими именами, например, cronie.service заменяет демон crond; alsa-store.service и alsa-restore.service заменяют демон alsa. Другой важный пример - демон network, которого сменил целый набор сервис-файлов (обратитесь к разделу #Сеть для получения дальнейшей информации.)
Tip: Вы можете заглянуть вовнутрь пакета, содержащего стартовые скрипты демона, чтобы узнать имена его сервис-файла. К примеру:
$ pacman -Ql cronie
[...]
cronie /etc/rc.d/crond                            #демон initscript, указываемый в массивеe DAEMONS (не используется при "чистой" настройке systemd)
[...]
cronie /usr/lib/systemd/system/cronie.service     #Соответствующий сервис systemd
[...]

Writing custom .service files

Handling dependencies

With systemd, dependencies can be resolved by designing the unit files correctly. The most typical case is that the unit A requires the unit B to be running before A is started. In that case add Requires=B and After=B to the [Unit] section of A. If the dependency is optional, add Wants=B and After=B instead. Note that Wants= and Requires= do not imply After=, meaning that if After= is not specified, the two units will be started in parallel.

Dependencies are typically placed on services and not on targets. For example, network.target is pulled in by whatever service configures your network interfaces, therefore ordering your custom unit after it is sufficient since network.target is started anyway.

Type

There are several different start-up types to consider when writing a custom service file. This is set with the Type= parameter in the [Service] section. See man systemd.service for a more detailed explanation.

  • Type=simple: systemd considers the service to be started up immediately. The process must not fork. Do not use this type if other services need to be ordered on this service, unless it is socket activated.
  • Type=forking: systemd considers the service started up once the process forks and the parent has exited. For classic daemons use this type unless you know that it is not necessary. You should specify PIDFile= as well so systemd can keep track of the main process.
  • Type=oneshot: This is useful for scripts that do a single job and then exit. You may want to set RemainAfterExit= as well so that systemd still considers the service as active after the process has exited.
  • Type=notify: Identical to Type=simple, but with the stipulation that the daemon will send a signal to systemd when it is ready. The reference implementation for this notification is provided by libsystemd-daemon.so.
  • Type=dbus: The service is considered ready when the specified BusName appears on DBus's system bus.

Replacing provided unit files

The unit files in /etc/systemd/system/ take precedence over the ones in /usr/lib/systemd/system/. To make your own version of a unit (which will not be destroyed by an upgrade), copy the old unit file from /usr/lib/ to /etc/ and make your changes there. Alternatively you can use .include to parse an existing service file and then override or add new options. For example, if you simply want to add an additional dependency to a service file, you may use:

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

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

Then run the following for your changes to take effect:

# systemctl reenable <unit>
# systemctl restart <unit>
Tip: You can use systemd-delta to see which unit files have been overridden and what exactly has been changed.

Syntax highlighting for systemd unit files within Vim

Syntax highlighting for systemd unit files within Vim can be enabled by installing vim-systemdAUR from the AUR.

Оптимизация

systemd-analyze

Systemd provides a tool called systemd-analyze that allows you to analyze your boot process so you can see which unit files are causing your boot process to slow down. You can then optimize your system accordingly. You have to install python2-dbus and python2-cairo to use it.

To see how much time was spent in kernel-/userspace on boot, simply use:

$ systemd-analyze
Tip: To see how much time was spent in the initramfs, add the timestamp hook to your HOOKS array in /etc/mkinitcpio.conf and as root, rebuild your initramfs with mkinitcpio -p linux

To list the started unit files, sorted by the time each of them took to start up:

$ systemd-analyze blame

You can also create a SVG file which describes your boot process graphically, similiar to Bootchart:

$ systemd-analyze plot > plot.svg

Enabling bootchart in conjunction with systemd

You can use a version of bootchart to visualize the boot sequence. Since you are not able to put a second init into the kernel command line you won't be able to use any of the standard bootchart setups. However the bootchart2AUR package from AUR comes with an undocumented systemd service. After you've installed bootchart2 do:

# systemctl enable bootchart.service

Read the bootchart documentation for further details on using this version of bootchart.

Shell Shortcuts

systemd daemon management requires a bit more text entry to accomplish tasks such as start, stopped, enabling, checking status, etc. The following functions can be added to one's ~/.bashrc file to help streamline interactions with systemd and to improve the overall experience.

# simplified systemd command, for instance "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
# start systemd service
    0.start() {
        sudo systemctl start $1.service
    }
# restart systemd service
    0.restart() {
        sudo systemctl restart $1.service
    }
# stop systemd service
    0.stop() {
        sudo systemctl stop $1.service
    }
# enable systemd service
    0.enable() {
        sudo systemctl enable $1.service
    }
# disable a systemd service
    0.disable() {
        sudo systemctl disable $1.service
    }
# show the status of a service
    0.status() {
        systemctl status $1.service
    }
# reload a service configuration
    0.reload() {
        sudo systemctl reload $1.service
    }
# list all running service
    0.list() {
        systemctl
    }
# list all failed service
    0.failed () {
        systemctl --failed
    }
# list all systemd available unit files
    0.list-files() {
        systemctl list-unit-files
    }
# check the log
    0.log() {
        sudo journalctl
    }
# show wants
    0.wants() {
        systemctl show -p "Wants" $1.target
    }
# analyze the system
    0.analyze() {
        systemd-analyze $1
    }
fi

Less output

Change verbose to quiet on the bootloader's kernel line. For some systems, particularly those with an SSD, the slow performance of the TTY is actually a bottleneck, and so less output means faster booting.

Early start

One central feature of systemd is D-Bus and socket activation, this causes services to be started when they are first accessed, and is generally a good thing. However, if you know that a service (like ConsoleKit) will always be started during boot, then the overall boot time might be reduced by starting it as early as possible. This can be achieved (if the service file is set up for it, which in most cases it is) by issuing:

# systemctl enable console-kit-daemon.service

This will cause systemd to start ConsoleKit as soon as possible, without causing races with the socket or D-Bus activation.

Automount

The default setup will fsck and mount all filesystems before starting most daemons and services. If you have a large /home partition, it might be better to allow services that do not depend on /home to start while /home is being fsck'ed. This can be achieved by adding the following options to the fstab entry of your /home partition:

noauto,x-systemd.automount

This will fsck and mount /home when it is first accessed, and the kernel will buffer all file access to /home until it is ready.

If you have encrypted filesystems with keyfiles, you can also add the noauto parameter to the corresponding entries in /etc/crypttab. systemd will then not open the encrypted device on boot, but instead wait until it is actually accessed and then automatically open it with the specified keyfile before mounting it. This might save a few seconds on boot if you are using an encrypted RAID device for example, because systemd doesn't have to wait for the device to become available. For example:

/etc/crypttab
data /dev/md0 /root/key noauto

Readahead

systemd comes with its own readahead implementation, this should in principle improve boot time. However, depending on your kernel version and the type of your hard drive, your mileage may vary (i.e. it might be slower). To enable, do:

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

Remember that in order for the readahead to work its magic, you should reboot a couple of times.

Замена 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>
Note: При использовании NetworkManager вам необходимо перекомпилировать данный пакет с поддержкой systemd из ABS путем записи опции --with-session-tracking=systemd в PKGBUILD.

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

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

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

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