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

From ArchWiki
Jump to: navigation, search
(Управлением питанием ACPI)
(Некоторая правка и приведение в соотвестствие с английской вики (по состоянию на 02:46, 17 ноября 2012))
Line 39: Line 39:
 
Следующий раздел предназначен для тех установок Arch Linux, которые все еще зависят от пакетов {{pkg|sysvinit}} и {{pkg|initscripts}} и не перешли на использование {{pkg|systemd}}.
 
Следующий раздел предназначен для тех установок Arch Linux, которые все еще зависят от пакетов {{pkg|sysvinit}} и {{pkg|initscripts}} и не перешли на использование {{pkg|systemd}}.
 
 
 
 
# Установите пакет {{pkg|systemd}} и добавьте следующую запись к командной строке загрузки ядра: {{ic|1=init=/usr/lib/systemd/systemd}}
+
# Установите пакет {{pkg|systemd}} и добавьте следующую запись к [[kernel_line|параметрам загрузки ядра]]: {{ic|1=init=/usr/lib/systemd/systemd}}
 
# выполнив это, вы сможете включать или отключать любой необходимый сервис путем применения команды {{ic|systemctl enable <service_name>}} (это примерно соответствует тому, что включалось в  массив {{ic|DAEMONS}}).
 
# выполнив это, вы сможете включать или отключать любой необходимый сервис путем применения команды {{ic|systemctl enable <service_name>}} (это примерно соответствует тому, что включалось в  массив {{ic|DAEMONS}}).
 
# Перезагрузите свою систему и убедитесь, что {{ic|systemd}} в настоящее время активен, выполнив слудующую команду: {{ic|$ cat /proc/1/comm}}. Данная команда должна вернуть строку {{ic|systemd}}.
 
# Перезагрузите свою систему и убедитесь, что {{ic|systemd}} в настоящее время активен, выполнив слудующую команду: {{ic|$ cat /proc/1/comm}}. Данная команда должна вернуть строку {{ic|systemd}}.
 
# Удалите {{pkg|initscripts}} и {{pkg|sysvinit}} из вашей системы и установите {{pkg|systemd-sysvcompat}}.
 
# Удалите {{pkg|initscripts}} и {{pkg|sysvinit}} из вашей системы и установите {{pkg|systemd-sysvcompat}}.
# В последнюю очередь удалите параметр {{ic|1=init=/usr/lib/systemd/systemd}}, поскольку необходимости в нем более нет.
+
# Теперь можно (но не обязательно) удалить параметр {{ic|1=init=/usr/lib/systemd/systemd}}, поскольку необходимости в нем более нет. Инициализация по умолчанию обеспечивается пакетом {{pkg|systemd-sysvcompat}}.
  
 
=== Дополнительная информация ===
 
=== Дополнительная информация ===
Line 94: Line 94:
  
 
{{hc|/etc/vconsole.conf|2=
 
{{hc|/etc/vconsole.conf|2=
KEYMAP=ru4
+
KEYMAP=ru
 
FONT=UniCyr_8x16
 
FONT=UniCyr_8x16
 
}}
 
}}
Line 102: Line 102:
 
Другой способ настройки раскладки клавиатуры в консоли состоит в использовании команды:
 
Другой способ настройки раскладки клавиатуры в консоли состоит в использовании команды:
  
  # localectl set-keymap ru4
+
  # localectl set-keymap ru
  
 
Преимущество такого подхода - в том, что он также установит указанную раскладку клавиатуры и для X11.
 
Преимущество такого подхода - в том, что он также установит указанную раскладку клавиатуры и для X11.
Line 115: Line 115:
 
  # timedatectl set-timezone Europe/Moscow
 
  # timedatectl set-timezone Europe/Moscow
  
Для получения подробной информации о вариантах настройки обратитесь к руководствам {{ic|man 1 timedatectl}} и {{ic|man 5 localtime}} и {{ic|man 7 archlinux}}.
+
Для получения подробной информации о вариантах настройки обратитесь к руководствам {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} и {{ic|man 7 archlinux}}.
  
 
{{Note|Прежний конфигурационный файл {{ic|/etc/timezone}} объявлен устаревшим с выходом {{pkg|systemd}}-190 и должен быть удален.}}
 
{{Note|Прежний конфигурационный файл {{ic|/etc/timezone}} объявлен устаревшим с выходом {{pkg|systemd}}-190 и должен быть удален.}}
  
 
Альтернативный метод - создание символической ссылки вручную:
 
Альтернативный метод - создание символической ссылки вручную:
<!-- использовать относительную символическую ссылку! -->
+
<!-- НЕ СОЗДАВАЙЬТЕ АБСОЛЮТНУЮ СИМВОЛИЧЕСКУЮ ССЫЛКУ, руководство archlinux(7) ясно указывает, что это должна быть относительная символическая ссылка -->
 +
 
 
  # ln -sf ../usr/share/zoneinfo/Europe/Moscow /etc/localtime
 
  # ln -sf ../usr/share/zoneinfo/Europe/Moscow /etc/localtime
  
Line 735: Line 736:
 
*[http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions FAQ (англ.)]
 
*[http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions FAQ (англ.)]
 
*[http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks Tips And Tricks (англ.)]
 
*[http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks Tips And Tricks (англ.)]
*[http://0pointer.de/public/systemd-ebook-psankar.pdf systemd для администраторов (PDF) - перевод цикла статей Леннарта Поттеринга (Lennart Poettering) (англ.)]
+
*[http://0pointer.de/public/systemd-ebook-psankar.pdf systemd для администраторов (PDF) - перевод цикла статей Леннарта Поттеринга (Lennart Poettering)]
 
*[http://0pointer.de/blog/projects/systemd.html Блог Lennart'а (англ.)]
 
*[http://0pointer.de/blog/projects/systemd.html Блог Lennart'а (англ.)]
 
*[http://archlinux.org.ru/forum/viewtopic.php?f=9&t=9581 systemd mini FAQ]
 
*[http://archlinux.org.ru/forum/viewtopic.php?f=9&t=9581 systemd mini FAQ]

Revision as of 06:30, 17 November 2012

Сводка help replacing me
Статья охватывает установку и настройку systemd.
Связанные статьи
systemd/User
systemd/Services
systemd FAQ
init Rosetta (Русский)
udev (Русский)

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

"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, но если вы не хотите, можете не отказываться от использования традиционных демонов.
  • Интерактивные загрузочные скрипты (initscripts) не работают с systemd. В частности, netcfg-menu не может использоваться при загрузке системы.

Установка

Note: Оба пакета - systemd и systemd-sysvcompat - ставаятся по умолчанию при установке с носителя новее, чем 2012-10-13.

Следующий раздел предназначен для тех установок 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. Удалите initscripts и sysvinit из вашей системы и установите systemd-sysvcompat.
  5. Теперь можно (но не обязательно) удалить параметр init=/usr/lib/systemd/systemd, поскольку необходимости в нем более нет. Инициализация по умолчанию обеспечивается пакетом systemd-sysvcompat.

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

  • Если в параметрах ядра имеется значение quiet, вероятно, вам стоит удалить его для нескольких первых загрузок systemd, чтобы видеть возникающие во время загрузке проблемы.
  • Теперь добавлять вашего пользователя в группы (optical, audio, scanner, ...) в большинстве случаев нет необходимости при использовании systemd. Это даже может нарушить работоспособность системы. Например, добавление в группу audio может привести к невозможности быстрого переключения между пользователями и позволит приложениям заблокировать программное микширование. Каждый вход PAM предоставляет сессию login, которое дает вам разрешения для локальной сессии посредством POSIX ACLs на аудио/видео устройства и позволяет выполнять некоторые операции, такие, как как монтирование съемных носителей через udisks
Note: Systemd-logind заменил ConsoleKit, удаленный из репозиториев, поэтому для полной функциональности теперь система должна загружаться с использованием systemd. Смотрите новость для получения дальнейшей информации.} Ранее ConsoleKit обеспечивал подобные разрешения для устройств на основе ACL и разрешения polkit для локальных сессий.

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

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

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

Имя компьютера настраивается в файле /etc/hostname. Этот файл не должен содержать системный домен (если таковой имеется). Для установки имени компьютера выполните:

# hostnamectl set-hostname myhostname

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

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

/etc/hostname
myhostname

Локаль

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

# localectl set-locale LANG="ru_RU.UTF-8"
Note: Перед установкой локали по умолчанию вам сперва необходимо сделать локали доступными системе, раскомментировав их в файле /etc/locale.gen и затем выполнив команду locale-gen от суперпользователя root. Локаль, установленная командой localectl, должна быть одной из раскомментированных локалей в файле /etc/locale.gen.

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

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

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

/etc/locale.conf
LANG=ru_RU.utf8

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

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

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

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

# localectl set-keymap ru

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

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

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

Временная зона настраивается путем создания соответствующей символической ссылки /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

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

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

Если вы настроите 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.

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

Добавление модулей в черный список работает также, как и в случае с 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 до готовности данного раздела.

  • То же самое применимо и к удаленным файловым системам. Если вы хотите, чтобы монтирование данных систем происходило только по мере доступа к ним, вы можете использовать параметр 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.service (предоставляемый пакетом lvm2):

# systemctl enable lvm

Точно так же, если у вас LVM на устройствах с шифрованием, монтируемым позже в процессе загрузки (например, из /etc/crypttab), вам необходимо включить сервис lvm-on-crypt.service (также предоставляемый пакетом lvm2):

# systemctl enable lvm-on-crypt

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

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

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

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

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. Вы вы можете увидеть данный выход в журнале systemd:

# journalctl -b -u systemd-suspend

Обратите внимание, что вместо использования скриптов вы также можете использовать специальные целевые юниты - sleep.target, suspend.target или hibernate.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

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

Юнит

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

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

Переход от initscripts к использованию systemd

Эмуляция initscripts

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

  1. Проводить синтаксический разбор массива DAEMONS в файле /etc/rc.conf и запускать при загрузке все находящиеся там демоны (см. ниже)
  2. Выполнять при загрузке /etc/rc.local
  3. Выполнять при завершении работы системы /etc/rc.local.shutdown

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

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

Отказ от массива DAEMONS

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

# systemctl enable <service_name>
Tip: Для получения списка обычно используемых демонов с их эквивалентами в initscripts и systemd, обратитесь к данной таблице.

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

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

Сравнительная таблица устаревшей и "родной" конфигураций

Warning: Данный раздел оставлен в русской версии временно, до полной миграции пользователей на использование "чистого" systemd.
Настройка Конфигурационный файл (файлы) Устаревшая секция 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

Эмуляция /etc/rc.local

Warning: Данный раздел оставлен в русской версии временно, до полной миграции пользователей на использование "чистого" systemd.

Если вы хотите при использовании systemd сохранить простоту /etc/rc.local , вам нужно создать следующий сервис-файл и включить его. Просто добавьте строки ExecStart= для тех команд, которые вы хотите запустить. Если же вам в данном случае требуется более сложная функциональность (например, циклы с for), то вы можете создать скрипт Bash и выполнять его из сервис-файла. Удалите ExecStart=/bin/true, если вы здесь действительно добавляете команду.

/etc/systemd/system/rc-local.service
[Unit]
Description=/etc/rc.local compatibility

[Service]
Type=oneshot
ExecStart=/bin/true
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

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

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

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

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

$ systemctl reboot

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

$ systemctl poweroff

Завершить работу и остановить систему:

$ systemctl halt

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

$ systemctl suspend

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

$ systemctl hibernate

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

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

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

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

Уровни запуска (по-английски уровень запуска - 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/ не существует (например, вы или какая-либо программа удалили ее), systemd не создаст ее автоматически, но вместо этого запишет свои логи в директорию /run/systemd/journal. Это означает, что логи будут потеряны при перезагрузке.

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

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

Примеры:

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

# journalctl -b

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

# 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

Сеть

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

Динамическое подключение (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 как показано в предыдущем параграфе.

Оптимизация

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

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

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

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

$ systemd-analyze
Tip: Чтобы увидеть, сколько времени ушло на загрузку образа initramfs, дополните хуком timestamp ваш массив HOOKS из конфигурационного файла /etc/mkinitcpio.conf и от суперпользователя root пересоберите ваш образ initramfs командой mkinitcpio -p linux

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

$ systemd-analyze blame

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

$ systemd-analyze plot > plot.svg

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

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

# systemctl enable bootchart

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

Readahead

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

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

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

Ранний старт сервисов

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

# systemctl enable upower

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

Уменьшение вывода во время загрузки

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

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

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

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

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