systemd (Русский)

From ArchWiki
Jump to: navigation, search
Сводка
Статья охватывает установку и настройку systemd.
Связанные статьи
systemd/User
systemd/Services
systemd FAQ
init Rosetta (Русский)
udev (Русский)

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

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

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

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

Contents

Соображения перед началом миграции

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

Установка

Note: Оба пакета - systemd и systemd-sysvcompat - ставятся по умолчанию при установке с носителя новее, чем 2012-10-13.
Note: Если вы запускаете Arch Linux в виртуальном выделенном сервере (VPS), пожалуйста, обратитесь к соответствующей странице вики (англ.).

Следующий раздел предназначен для тех установок Arch Linux, которые все еще зависят от пакетов sysvinit и initscripts и не перешли на использование systemd.

  1. Установите пакет systemd и добавьте следующую запись к параметрам загрузки ядра: init=/usr/lib/systemd/systemd
  2. Выполнив это, вы сможете включать или отключать любой необходимый сервис путем применения команды systemctl enable <service_name> (это примерно соответствует тому, что включалось в массив DAEMONS). Новые имена (отличные от прежних демонов) можно посмотреть здесь.
  3. Перезагрузите свою систему и убедитесь, что systemd в настоящее время активен, выполнив следующую команду: cat /proc/1/comm. Данная команда должна вернуть строку systemd.
  4. Убедитесь, что hostname (имя компьютера) у вас под systemd установлено праильно: hostnamectl set-hostname myhostname.
  5. Удалите initscripts и sysvinit из вашей системы и установите systemd-sysvcompat.
  6. Теперь можно (но не обязательно) удалить параметр init=/usr/lib/systemd/systemd, поскольку необходимости в нем более нет. Инициализация по умолчанию обеспечивается пакетом systemd-sysvcompat.

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

  • Если в параметрах ядра имеется значение quiet, вероятно, вам стоит удалить его для нескольких первых загрузок systemd, чтобы видеть возникающие во время загрузки проблемы.
  • Теперь при использовании systemd добавлять вашего пользователя в группы (sys, disk, lp, network, video, audio, optical, storage, scanner, power и др.)) в большинстве случаев нет необходимости. Это даже может нарушить работоспособность системы. Например, добавление в группу audio может привести к невозможности быстрого переключения между пользователями и позволит приложениям заблокировать программное микширование. Каждый вход PAM предоставляет сессию logind, которая дает вам разрешения для локальной сессии посредством POSIX ACLs на аудио/видео устройства и позволяет выполнять некоторые операции, такие, как как монтирование съемных носителей через udisks.
  • Обратитесь к статье Network Configuration для получения информации о настройке сетевых подключений.

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

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

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

Warning: Этот раздел сохранен в русской версии статьи временно. В английской версии он перемещен в статью Network Configuration.

Имя компьютера настраивается в файле /etc/hostname. Этот файл может содержать содержать доменное имя системы, если таковое имеется, однако в момент написания руководства команда hostnamectl не устанавливала FQDN (Fully Qualified Domain Name — полностью определенное имя домена). Для установки короткого имени компьютера выполните: 

# hostnamectl set-hostname myhostname

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

Вот примерный файл: 

/etc/hostname
myhostname

Локаль

Warning: Этот раздел сохранен в русской версии статьи временно. В английской версии он перемещен в статью Locale.
Note: Перед установкой локали по умолчанию вам сперва необходимо сделать локали доступными системе, раскомментировав их в файле /etc/locale.gen (т.е. убрать знак # вначале строки) и затем выполнив команду locale-gen от суперпользователя root. Локаль, установленная командой localectl, должна быть одной из раскомментированных локалей в файле /etc/locale.gen.

Системная локаль по умолчанию настраивается в конфигурационном файле /etc/locale.conf. Для установки локали по умолчанию выполните: 

# localectl set-locale LANG="ru_RU.UTF-8"

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

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

Вот примерный файл: 

/etc/locale.conf
LANG=ru_RU.utf8

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

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

/etc/vconsole.conf
KEYMAP=ru
FONT=cyr-sun16
Note: С версии systemd-194 используются шрифт ядра и раскладку по умолчанию (т.е. американскую английскую). Нет более необходимости (для тех, кто использует американскую английскую раскладку) настраивать в конфигурационном файле строки KEYMAP= и FONT=, их можно оставить пустыми.

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

# localectl set-keymap ru

Команда localectl также может быть использована для установки раскладки клавиатуры в X11: 

# localectl set-x11-keymap ru

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

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

Warning: Этот раздел сохранен в русской версии статьи временно. В английской версии он перемещен в статью Time#Time.

Временная зона настраивается путем создания соответствующей символической ссылки /etc/localtime на файл временной зоны в директории /usr/share/zoneinfo/. Чтобы сделать это автоматически, выполните команду: 

# timedatectl set-timezone Europe/Moscow

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

Note: Прежний конфигурационный файл /etc/timezone объявлен устаревшим с выходом systemd-190 и должен быть удален.

Альтернативный метод - создание символической ссылки вручную: 

# ln -sf ../usr/share/zoneinfo/Europe/Moscow /etc/localtime

Если в вашей системе имеется прежний конфигурационный файл /etc/timezone, он теперь может быть безопасно удален, поскольку не используется systemd.

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

Systemd будет использовать UTC для аппаратных часов по умолчанию.

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

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

Если вы собираетесь выставить аппаратные часы по localtime (местному времени, что КАТЕГОРИЧЕСКИ НЕ РЕКОМЕНДУЕТСЯ), выполните команду: 

# timedatectl set-local-rtc true

Если же захотите вернуть ваши аппаратные часы к использованию временного формата UTC, выполните: 

# timedatectl set-local-rtc false

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

Причиной, позволяющей RTC быть выставленными по местному времени, является двойная загрузка системы с Windows, (которая использует localtime (англ.)). Windows воспринимает RTC, выставленные по UTC при помощи простого исправления реестра (англ.). Рекомендуется настроить Windows на использование UTC, а не Linux на местное время. Если вы настроите Windows на использование UTC, также не забудьте отключить функцию "Обновление времени по Интернету" ("Internet Time Update"), иначе для Windows возникнет проблема с аппаратными часами, поскольку система будет пытаться синхронизировать их с временем через Интернет. Вместо этого следует оставить время в формате RTC и синхронизовать через Интернет в Linux посредством демона NTP, как это предлагалось выше.

  • За дальнейшей информацией обратитесь к статье Time.

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

Сегодня все необходимые модули для загрузки подгружаются автоматически с помощью Udev, так что, если вам не надо (или же вы не должны) использовать какой-нибудь модуль не из дерева ядра , нет необходимости дополнительно помещать какие-либо модули в какой-то файл конфигурации загрузки. Тем не менее, бывают случаи, когда вы можете подгрузить дополнительный модуль в процессе загрузки или поместить какой-то модуль в черный список, чтобы ваш компьютер работал правильно.

Дополнительно подгружаемые при загрузке модули

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

Более подробная информация содержится в руководстве man 5 modules-load.d.

Настройка параметров модулей

Дополнительные параметры модулей должны устанавливаться в конфигурационном файле /etc/modprobe.d/modprobe.conf.

Например:

  • мы имеем /etc/modules-load.d/loop.conf с прописанным модулем loop для подгрузки его во время загрузки системы.
  • в файле /etc/modprobe.d/modprobe.conf определяются дополнительные параметры, такие, как options loop max_loop=64.

Затем вновь установленные параметры могут быть проверены с помощью команды cat /sys/module/loop/parameters/max_loop.

Черный список

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

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

Установка по умолчанию автоматически проверяет файловые системы командой fsck и монтирует файловые системы перед запуском тех сервисов, котрым необходимо иметь эти системы примонтированными. Например, systemd позволяет в автоматическом режиме добиться, что удаленные файловые системы наподобие NFS и Samba подключаются после поднятия сети. Поэтому монтирование как локальных, так и удаленных файловых систем, прописанных в /etc/fstab должно работать "из коробки".

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

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

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

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

Note: Таким образом для вашей файловой системы /home при монтировании будет установлен тип autofs, который по умолчанию игнорируется утилитой mlocate. Скорость автомонирования /home при этом не увеличится более чем на одну или две секунды,в зависимости от вашей системы, поэтому данный труюк, возможно, не стоит применять.
  • То же самое применимо и к удаленным файловым системам. Если вы хотите, чтобы монтирование данных систем происходило только по мере доступа к ним, вы можете использовать параметр x-systemd.device-timeout=# в файле /etc/fstab для определения таймаута в том случае, кода сетевые ресурсы оказываются недоступны.
  • В случае использования зашифрованных файловых систем с ключами доступа, вам также Iследует добавить параметр noauto в соответствующие записи файла /etc/crypttab. systemd не будет подключать зашифрованные устройства при загрузке, но, вместо этого, дождется реального обращения к ним и автоматически откроет к ним доступ с использованием определенных ключей перед тем, как они будут примонтированы. Это сэкономит несколько секунд при загрузке системы, например, в случае использования зашифрованного устройства RAID, потому что systemd не будет дожидаться от устройства, когда оно станет доступным. Например: 
/etc/crypttab
data /dev/md0 /root/key noauto

LVM

Если у вас имеются тома LVM, не активированные посредством initramfs, включите сервис lvm-monitoring, который предоставляется пакетом lvm2: 

# systemctl enable lvm-monitoring

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

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

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

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

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

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

Note: Выполните команду systemctl restart systemd-logind, чтобы изменения вступили в силу.
Note: Systemd не может обрабатывать события AC и Battery ACPI, поэтому, если вы используете Laptop Mode Tools или другие аналогичные утилиты, по-прежнему требуется acpid.

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

Warning: В настоящее время менеджеры управления питанием в новейших версиях сред KDE и GNOME являются единственными, которые используют такие команды "подавления". До тех пор, пока их не будут применять другие менеджеры, вам надо выставить в параметрах Handle значение ignore, если вы хотите, чтобы события ACPI обрабатывались в случае использования Xfce, acpid или других программ.
Note: Systemd также может использовать для перевода системы в спящий/ждущий режим другие движки (такие, как Uswsusp или TuxOnIce), в дополнение к движку ядра.

Чтобы команда systemctl hibernate заработала в вашей системе, вам необходимо следовать инструкциям из раздела Hibernation, а также, возможно, из раздела Mkinitcpio Resume Hook (не требуется устанавливать pm-utils).

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

Systemd в своих командах systemctl suspend, {ic|systemctl hibernate}} или systemctl hybrid-sleep не использует pm-utils для "усыпления" машины; хуки pm-utils, включая любые пользовательские хуки не будут работать. Тем не менее, systemd предоставляет два схожих механизма запуска пользовательских скриптов для данных событий.

Сервис-файлы для спящего режима/возобновления работы

Сервис-файлы могут быть подключены к suspend.target, hibernate.target и sleep.target для выполнения действий до или после перевода системы в спящий/ждущий режимы. Отдельные файлы следует создавать для пользовательских действий или системных действий/действий, выполняемых суперпользователем root. Для включения пользовательских сервис-файлов, выполните команду # systemctl enable suspend@<user> && systemctl enable resume@<user>. Примеры: 

/etc/systemd/system/suspend@.service
[Unit]
Description=User suspend actions
Before=sleep.target

[Service]
User=%I
Type=forking
Environment=DISPLAY=:0
ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop ; /usr/bin/mysql -e 'slave stop'
ExecStart=/usr/bin/sflock

[Install]
WantedBy=sleep.target
/etc/systemd/system/resume@.service
[Unit]
Description=User resume actions
After=suspend.target

[Service]
User=%I
Type=simple
ExecStartPre=/usr/local/bin/ssh-connect.sh
ExecStart=/usr/bin/mysql -e 'slave start'

[Install]
WantedBy=suspend.target

Для действий суперпользователя root/системных действий (включается командой # systemctl enable root-suspend): 

/etc/systemd/system/root-resume.service
[Unit]
Description=Local system resume actions
After=suspend.target

[Service]
Type=simple
ExecStart=/usr/bin/systemctl restart mnt-media.automount

[Install]
WantedBy=suspend.target
/etc/systemd/system/root-suspend.service
[Unit]
Description=Local system suspend actions
Before=sleep.target

[Service]
Type=simple
ExecStart=-/usr/bin/pkill sshfs

[Install]
WantedBy=sleep.target

Несколько полезных советов по поводу этих сервис-файлах (подробности командой man systemd.service):

  • В случае Type=OneShot вы можете использовать несколько строк ExecStart=. В противном случае допустима только одна строка ExecStart. Можно добавить больше команд либо при помощи ExecStartPre, либо отдельными командами, разделенными точкой с запятой (;) (смотрите первый пример из приведенных выше - обратите внимание на пробелы до и после точки с запятой... это необходимо!).
  • Команды с префиксом '-' приведут к ненулевому (не "0") статусу выхода, который проигнорируется и будет рассматриваться как успешное завершение команды.
  • Лучший способ обнаружения ошибок при диагностике данных сервис-файлов - конечно же, команда journalctl.
Комбинированный сервис-файл спящего режима/возобновления работы

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

Пример и объяснение: 

/etc/systemd/system/wicd-sleep.service
[Unit]
Description=Wicd sleep hook
Before=sleep.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=-/usr/share/wicd/daemon/suspend.py
ExecStop=-/usr/share/wicd/daemon/autoconnect.py

[Install]
WantedBy=sleep.target
  • RemainAfterExit=yes: После запуска сервис считается активным, пока не будет явно остановлен.
  • StopWhenUnneeded=yes: В случае, если сервис активен, он может быть остановлен, если нет нуждающихся в нем других активных сервисов. В данном примере он будет остановлен после остановки целевого файла sleep.target.
  • Поскольку sleep.target. используемый такими целевыми юнатами, как suspend.target, hibernate.target, hybrid-sleep.target и самим sleep.target является сервисом StopWhenUnneeded, хук гарантирует старт/остановку различных задач должным образом.
Хуки в /usr/lib/systemd/system-sleep

Systemd запускает все исполняемые файлы в директории /usr/lib/systemd/system-sleep/, передавая каждому из них два аргумента:

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

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

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

# journalctl -b -u systemd-suspend

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

Пример пользовательского скрипта по переходу в спящий режим: 

/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

Не забудьте сделать ваш скрипт исполняемым: 

# chmod a+x /usr/lib/systemd/system-sleep/example.sh

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

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

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

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

/usr/lib/tmpfiles.d/samba.conf
D /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

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

Юнит

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

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

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

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

Tip: Вы можете использовать приведенные ниже команды systemctl с ключом -H <user>@<host> для того, чтобы контролировать systemd на удаленной машине. В этом случае для соединения с удаленным процессом systemd будет использовать SSH.
Note: systemadm - официальная графическая оболочка для systemctl. Она доступна в виде пакета systemd-ui-git из 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 для получения детальной информации.

Note: При использовании юнитов следует обращать внимание на регистр букв в наименовании сервис-файлов: так, необходимо использовать NetworkManager.service (запомните употребление в данном названии букв в верхнем регистре) для включения сервиса NetworkManager'а, в противном случае вы получите сообщение об ошибке и сервис во время загрузки системы не запустится.

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

# 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 с поиском новых или измененных юнитов: 

# systemctl daemon-reload

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

Для управления питанием необходим polkit.

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

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

$ systemctl reboot

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

$ systemctl poweroff

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

$ systemctl suspend

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

$ systemctl hibernate

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

$ systemctl hybrid-sleep

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

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

# systemctl enable kdm

Эта команда должна работать "из коробки". Если вдруг она не сработала, то, возможно, у вас 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

Использование systemd-logind

Note: С 30.10.2012 ConsoleKit был заменен на systemd-logind как механизм входа в окружение рабочего стола по умолчанию.

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

$ loginctl show-session $XDG_SESSION_ID

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

Смотрите статью: Systemd/Services

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

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

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

Тип

Существует несколько различных типов запуска служб, которые надо иметь в виду при написании пользовательского сервис-файла. Тип запуска определяется параметром Type= в секции [Service]. Обратитесь к руководству man systemd.service для получения более детального объяснения.

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

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

Для того, чтобы отредактировать предоставляемый пакетом файл юнита, вы можете создать директорию {/etc/systemd/system/<unit>.d/ (например, /etc/systemd/system/httpd.service.d/) и поместить в нее файлы place *.conf, чтобы переопределить настройки данных файлов или чтобы добавить новые параметры. Systemd проведет парсинг данный файлов *.conf и применит их настройки поверх настроек поставляемого исходного юнита. Например, если вы просто хотите добавить в сервис-файл дополнительную зависимость, вы можете исоздать следующий файл: 

/etc/systemd/system/<unit>.d/customdependency.conf
[Unit]
Requires=<new dependency>
After=<new dependency>

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

# systemctl daemon-reload
# systemctl restart <unit>

В качестве другого варианта вы можете скопировать старый юнит из директории /usr/lib/systemd/system/ в директорию /etc/systemd/system/ aи применить свои изменения в последней директории. Юнит-файл в директории /etc/systemd/system/ всегда имеет приоритет и переопределяет настройки такого же юнита в директории /usr/lib/systemd/system/. Обратите внимание, что поставляемый исходный юнит в директории /usr/lib/ изменяется при обновлении пакета и эти изменения не будут автоматически применены к вашему отредактированному юниту в директории /etc/. Дополнительно вы должны вручную выполнить команду systemctl reenable <unit>, чтобы изменения вступили в силу. В силу указанных соображений рекомендуется вместо данного варианта использовать описанный выше метод с файлами в директории *.conf.

Tip: Вы можете использовать команду systemd-delta, чтобы увидеть, какие файлы юнитов были переопределены и что в точности было изменено. Поскольку файлы, предоставляющие юниты, будут время от времени обновляться, используйте для обслуживания системы systemd-delta.

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

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

Уровни запуска/цели

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

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

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

$ systemctl list-units --type=target

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

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

# systemctl isolate graphical.target

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

Изменение цели для загрузки

Стандартная цель - 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; символическая ссылка на новый целевой юнит по умолчанию создается в директории /etc/systemd/system/default.target. Это сработает в том случае (и только в том случае), если имеется следующая секция: 

[Install]
Alias=default.target

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

Журнал

С версии 38 systemd имеет собственную систему ведения логов - журнал (journal). По умолчанию, более не требуется запуск демона syslog. Для чтения логов используйте команду: 

# journalctl

По умолчанию (когда в конфигурационном файле /etc/systemd/journald.conf параметр Storage= имеет значение auto) журнал записывается в директорию /run/systemd/journal. Директория /var/log/journal/ создается при установке core/systemd. В случае, если вы или какая-либо программа удалили ее), systemd не воссоздаст ее автоматически , но при следующем обновлении systemd эта директория будет восстановлена. До восстановления данной директории, логи будут записываться в директорию /run/systemd/journal. Это означает, что логи будут потеряны при перезагрузке.

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

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

Примеры:

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

# journalctl -b

Однако часто интерес представляют сообщения, выданные во время не текущей, а предыдущей загрузки системы (например, если произошел неустраненный аварийный отказ системы). В настоящее время данная функция еще не реализована, хотя прошла дискуссия на systemd-devel@lists.freedesktop.org (сентябрь/октябрь 2012).

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

# journalctl --since=today | tac | sed -n '/-- Reboot --/{n;:r;/-- Reboot --/q;p;n;b r}' | tac

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

Последние сообщения: 

# journalctl -f

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

# journalctl /usr/lib/systemd/systemd

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

# journalctl _PID=1

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

#  journalctl -u netcfg

Обратитесь к 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 в репозиториях автоматически предоставляется необходимая конфигурация. 

# systemctl enable syslog-ng

Хорошее руководство по journalctl находится здесь (англ.)

Сеть

Warning: Данный раздел в английской версии включен в состав статьи Network Configuration; в русской версии временно оставлен из-за того, что русский вариант Configuring Network (Русский) устарел в сравнении с английским.

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

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

Сначала надо узнать наименование своего сетевого интерфейса командой ip addr. Чтобы подключить DHCP для <имя сетевого интерфейса>, просто выполните команду: 

# systemctl start dhcpcd@<имя сетевого интерфейса>.service

Например, если имя сетевого интерфейса enp9s0: 

# systemctl start dhcpcd@enp9s0.service

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

# systemctl enable dhcpcd@<имя сетевого интерфейса>.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 как показано в предыдущем параграфе.

Оптимизация

Warning: Данный раздел в оригинальной английской вики предлагается перенести в статью Improve Boot Performance.

Анализ процесса загрузки

Использование systemd-analyze

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

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

$ systemd-analyze
Tip:
  • Если вы дополните хуком timestamp ваш массивr HOOKS в конфигурационном файле /etc/mkinitcpio.conf и пересоберете ваш образ initramfs командой mkinitcpio -p linux, systemd-analyze сколько времени затрачивается на initramfs.
  • Если вы загружаетесь при помощи UEFI и используете загрузчик, в который имплементирова Boot Loader Interface от systemd (что в настоящий момент применено только в Gummiboot ), systemd-analyze дополнительно сможет показать, сколько времени затрачено на прошивку EFI сам загрузчик.

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

$ systemd-analyze blame

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

$ systemd-analyze plot > plot.svg

Использование systemd-bootchart

Bootchart объединен с systemd с 17 октября 2012 года и вы можете использовать его для загрузки также, как и оригинальный bootchart. Добавьте следующие команду к строке инициализации ядра: 

initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart

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

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

# systemctl enable bootchart

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

Readahead

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

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

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

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

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

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

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

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

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

Загрузитесь с указанными ниже параметрами командной строки ядра:

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

Для получения дополнительной информации обратитесь к странице проекта systemd More Debugging Information (англ.).

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

Retrieved from "https://wiki.archlinux.org/index.php?title=Systemd_(Русский)&oldid=260202"