From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Systemd and the translation is 83% complete.
Outdated translations are marked like this.

systemd — это современная замена SysV-подобных init и rc в Linux-системах. systemd поддерживается Gentoo в качестве альтернативной системы инициализации.

Switching init systems is a non trivial operation that has implications for how the system is configured, and sometimes for what software can be installed or not. Generally, an init system will be chosen at installation time (i.e. by downloading either a systemd or an openrc stage3 tarball), and only changed if necessary. In true Gentoo style, in addition to systemd and OpenRC, several init systems are supported.

If systemd is being unwantedly pulled in as a dependency, see Gentoo without systemd.


Если обновляетесь с версии <=sys-apps/systemd-203, проверьте статью по обновлению.

Все дистрибутивы строятся вокруг ядра Linux. Ядро является прослойкой между пользовательским программным обеспечением и физическим оборудованием. Gentoo предоставляет несколько вариантов исходного кода ядра. Полный список с описанием доступен в статье общие сведения о ядре.

Для систем на базе amd64, Gentoo рекомендует пакет sys-kernel/gentoo-sources.

Выберете подходящий исходный код ядра и установите с помощью emerge:

root #emerge --ask sys-kernel/gentoo-sources


systemd позволяет использовать многие современные возможности ядра Linux. На данный момент минимальная требуемая версия ядра — 2.6.39. В свежих версиях sys-kernel/gentoo-sources поддерживается удобный способ включения обязательных и опциональных параметров ядра для systemd (смотрите Ядро/Конфигурация для получения дополнительной информации):

ЯДРО Быстрая настройка, если используется gentoo-sources
Gentoo Linux --->
   Support for init systems, system and service managers --->
      [*] systemd

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

ЯДРО Обязательные параметры
General setup  --->
	[*] Control Group support --->
		[*]   Support for eBPF programs attached to cgroups
	[ ] Enable deprecated sysfs features to support old userspace tools
	[*] Configure standard kernel features (expert users)  --->
		[*] open by fhandle syscalls
		[*] Enable eventpoll support
		[*] Enable signalfd() system call
		[*] Enable timerfd() system call
	[*] Enable bpf() system call
[*] Networking support --->
	Networking options --->
		[*] Unix domain sockets
Device Drivers  --->
	Generic Driver Options  --->
		[*] Maintain a devtmpfs filesystem to mount at /dev
File systems  --->
	[*] Inotify support for userspace
	Pseudo filesystems  --->
		[*] /proc file system support
		[*] sysfs file system support
ЯДРО Рекомендуемые параметры
General setup  --->
	[*] Namespaces support  --->
		[*] Network namespace
[*] Enable the block layer  --->
	[*] Block layer SG support v4
Processor type and features  --->
	[*] Enable seccomp to safely compute untrusted bytecode
Networking support --->
	Networking options --->
		<*> The IPv6 protocol
Device Drivers  --->
	Generic Driver Options  --->
		()  path to uevent helper
		[ ] Fallback user-helper invocation for firmware loading
	Firmware Drivers  --->
		[*] Export DMI identification via sysfs to userspace
File systems --->
	<*> Kernel automounter support (supports v3, v4 and v5)
	Pseudo filesystems --->
		[*] Tmpfs virtual memory file system support (former shm fs)
		[*]   Tmpfs POSIX Access Control Lists
		[*]   Tmpfs extended attributes

Для UEFI систем, включите следующие:

ЯДРО Поддержка UEFI
[*] Enable the block layer  --->
	Partition Types  --->
		[*] Advanced partition selection
		[*]   EFI GUID Partition support
Processor type and features  --->
	[*] EFI runtime service support
Device Drivers  --->
        Firmware Drivers  --->
                EFI (Extensible Firmware Interface) Support -->
	                <*> EFI Variable Support via sysfs

Если в системе используется планировщик BFQ разработчиком также рекомендуется включить поддержку hierarchical scheduling:

ЯДРО Планировщик BFQ
IO Schedulers  --->
	<*> BFQ I/O scheduler
        [*]   BFQ hierarchical scheduling support

Наиболее актуальный список необходимых параметров можно найти в разделе «REQUIREMENTS» файла README.

Убедитесь, что /usr доступен во время загрузки

Если /usr расположен на отдельном разделе, используйте initramfs для монтирования /usr до запуска systemd. На данный момент это означает использование sys-kernel/dracut или sys-kernel/genkernel (начиная с версии 4.1). Выделите время для миграции:

root #emerge --ask sys-kernel/genkernel


root #emerge --ask sys-kernel/dracut

Если используете dracut, включите модуль usrmount, если он не включен автоматически, для монтирования /usr.

ФАЙЛ /etc/dracut.conf.d/usrmount.conf
# Включение модуля для Dracut
add_dracutmodules+=" usrmount "

Если используется genkernel, то до того, как пересобрать ядро, удостоверьтесь, что /usr указан в конфигурационном файле /etc/initramfs.mounts genkernel. Это позволит монтировать /usr во время загрузки initramfs:

ФАЙЛ /etc/initramfs.mounts
root #genkernel --install all

Смотрите Руководство по initramfs для других альтернатив.

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

Если используется LVM и система загружается с помощью initramfs, initramfs должна быть создана с через sys-kernel/genkernel. Для этого запустите:

root #genkernel --lvm <target>

<target> — это initramfs или любой другой genkernel target, реализующий создание initramfs. Чтобы получить дополнительную информацию, смотрите genkernel --help:

user $genkernel --help


USE flags for sys-apps/systemd System and service manager for Linux

acl Add support for Access Control Lists
apparmor Enable support for the AppArmor application security system
audit Enable support for sys-process/audit
boot Enable EFI boot manager and stub loader
cgroup-hybrid Default to hybrid (legacy) cgroup hierarchy instead of unified (modern).
cryptsetup Enable cryptsetup tools (includes unit generator for crypttab)
curl Enable support for uploading journals
dns-over-tls Enable DNS-over-TLS support
elfutils Enable coredump stacktraces in the journal
fido2 Enable FIDO2 support
gcrypt Enable use of dev-libs/libgcrypt for various features
gnutls Prefer net-libs/gnutls as SSL/TLS provider (ineffective with USE=-ssl)
homed Enable portable home directories
http Enable embedded HTTP server in journald
idn Enable support for Internationalized Domain Names
importd Enable import daemon
iptables Use libiptc from net-firewall/iptables for NAT support in systemd-networkd; this is used only if the running kernel does not support nftables
kernel-install Enable kernel-install
kmod Enable kernel module loading via sys-apps/kmod
lz4 Enable lz4 compression for the journal
lzma Support for LZMA compression algorithm
openssl Enable use of dev-libs/openssl for various features
pam Add support for PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip
pcre Add support for Perl Compatible Regular Expressions
pkcs11 Enable PKCS#11 support for cryptsetup and homed
policykit Enable PolicyKit (polkit) authentication support
pwquality Enable password quality checking in homed
qrcode Enable qrcode output support in journal
resolvconf Install resolvconf symlink for systemd-resolve
seccomp Enable seccomp (secure computing mode) to perform system call filtering at runtime to increase security of programs
secureboot Automatically sign efi executables using user specified key
selinux !!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur
split-usr Enable behavior to support maintaining /bin, /lib*, /sbin and /usr/sbin separately from /usr/bin and /usr/lib*
sysv-utils Install sysvinit compatibility symlinks and manpages for init, telinit, halt, poweroff, reboot, runlevel, and shutdown
test Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently)
tpm Enable TPM support
ukify Enable systemd-ukify
vanilla Disable Gentoo-specific behavior and compatibility quirks
xkb Depend on x11-libs/libxkbcommon to allow logind to control the X11 keymap
zstd Enable support for ZSTD compression


Активируйте USE-флаг systemd глобально (в файле make.conf). USE-флаг elogind должен быть отключен, чтобы избежать конфликтов с сервисом systemd-logind. Также можно переключиться на субпрофиль systemd, чтобы использовать стандартный набор флагов (в этом случае отпадает необходимость ручной правки make.conf):

root #eselect profile list

Обновите систему с новым профилем:

root #emerge -avDN @world
Once this command is complete, it is important follow the Configuration steps.

Проблемы с зависимостями

При замене OpenRC на systemd, могут возникнуть некоторые проблемы с зависимостями.

Если sys-apps/sysvinit блокирует sys-apps/systemd, попробуйте отключить sysv-utils USE-флаг для sys-apps/systemd. Вы можете включить этот USE-флаг позже (и переустановить sys-apps/systemd), если необходимо.

root #emerge --oneshot sys-apps/openrc
root #emerge --ask --depclean

If sys-apps/sysvinit is still blocking sys-apps/systemd, make sure it and sys-apps/openrc are not contained in the world file:

root #emerge --deselect sys-apps/openrc sys-apps/sysvinit

Если sys-fs/udev блокирует sys-apps/systemd, sys-fs/udev может быть выбран в файле world. Попробуйте решить эту проблему, отменив его выбор:

root #emerge --deselect sys-fs/udev

sys-apps/systemd содержит udev. После установки systemd, пакет sys-fs/udev может быть удалён, так как systemd разрешает зависимость virtual/udev.

Если ваша система предоставляет sys-fs/eudev, virtual/udev и virtual/libudev могут препятствовать установке systemd. Чтобы portage мог решить проблему, попробуйте переустановить виртуальные пакеты после установки USE-флага:

root #emerge --oneshot virtual/udev virtual/libudev


Это больше не является необходимым для sys-apps/systemd, когда включён USE-флаг sysv-utils. Он активен по умолчанию в Gentoo, начиная с версии 239.

Чтобы загрузиться с systemd, измените init, который запускает ядро (или initramfs).

Сервисы, настроенные для менеджера сервисов, который использовался ранее, не будут запускаться автоматически. Это обусловлено переходом на другой менеджер сервисов. Чтобы восстановить функциональность таких сервисов, как сетевые сервисы или login-менеджер, необходимо снова активировать эти сервисы. Больше информации об этом можно найти в секции сервисы далее в этой статье.
Если переход на systemd вызывает проблемы, всегда можно вернуться к стандартному менеджеру сервисов (OpenRC), изменив init. Это позволяет откатиться к исходному состоянию системы и перейти к решению проблем, руководствуясь соответствующей секцией этой статьи.

Следующие главы этой статьи покажут, как переключить init в некоторых загрузчиках или непосредственно в самом ядре.

GRUB Legacy (0.x)

Необходимо добавить агрумент init=/lib/systemd/systemd в командную строку ядра. Соответствующий отрывок grub.conf будет выглядеть примерно так:

ФАЙЛ /boot/grub/grub.confПример конфигурационного файла GRUB для systemd
title=Gentoo with systemd
root (hd0,0)
kernel /vmlinuz root=/dev/sda2 init=/lib/systemd/systemd

Если система всё-таки загружается с OpenRC, попробуйте использовать real_init вместо init.


При использовании grub-mkconfig добавьте опцию init в GRUB_CMDLINE_LINUX:

В этом нет необходимости, если используется initramfs, сгенерированную dracut с systemd внутри, так как initramfs запускает systemd.
ФАЙЛ /etc/default/grubНастройка GRUB для systemd
# Добавление параметров в командную строку ядра linux

Если конфигурационный файл GRUB написан вручную (только для опытных пользователей), добавьте параметр init= для команд linux или linux16.

ФАЙЛ /boot/grub/grub.cfgФрагмент примера конфигурации GRUB2
linux /vmlinuz-3.10.9 root=UUID=508868e4-54c6-4e6b-84b0-b3b28b1656b6 init=/lib/systemd/systemd


Yaboot - это загрузчик для оборудования на базе PowerPC под управлением Linux, в частности, систем New World ROM Macintosh.

Аргумент init=/lib/systemd/systemd должен быть добавлен непосредственно после командной строки ядра. Пример из yaboot.conf:

ФАЙЛ /etc/yaboot.confПример конфигурации yaboot для systemd

Чтобы изменения в файле yaboot.conf возымели эффект, нужно после каждых изменений запускать команду ybin.

В конфигурации ядра

Конфигурация init также может быть жёстко сконфигурирована в ядре. Смотрите Processor type and features -> Built-in kernel command line. Обратите внимание, что это работает и для GRUB Legacy, и для GRUB.


У systemd есть возможность обновляться в уже запущенной системе (без перезагрузки). После установки обновленной версии systemd, запустите следующую команду:

root #systemctl daemon-reexec


systemd поддерживает несколько конфигурационных файлов для настройки базовых параметров системы.

After installing systemd, run the following:

root #systemd-machine-id-setup
root #systemd-firstboot --prompt
root #systemctl preset-all
If systemd-firstboot is not ran, it will automatically run on next boot. However, it interrupts the normal boot process, preventing access to the system from users who don't have access to the interactive console - like accessing a server via SSH.
В то время, как некоторые параметры системной конфигурации могут быть обновлены путем внесения изменений в соответствующие им файлы, большинство настроек настраиваются с помощью утилит, которым необходим запущенный systemd. В этом случае, необходимо аккуратно перезагрузить компьютер в systemd и использовать требуемые утилиты hostnamectl, localectl и timedatectl.

Machine ID

Создайте machine ID работы журналирования. Это можно сделать следующей командой:

root #systemd-machine-id-setup
Команда systemd-machine-id-setup также влияет на службу systemd-networkd. Если вы не выполните эту команду, может произойти нечто странное, такое как отсутствие сетевых интерфейсов или неприменимость сетевых адресов.

Имя хоста

Чтобы установить имя хоста, создайте или измените /etc/hostname, просто прописав в нем желаемое имя.

Когда система загружена с systemd, используйте утилиту hostnamectl для редактирования /etc/hostname и /etc/machine-info. Чтобы изменить имя хоста, выполните:

root #hostnamectl set-hostname <HOSTNAME>

Для получения дополнительных параметров обратитесь к man hostnamectl.


При установке systemd, как правило, локали правильно переносятся из OpenRC. Когда требуется, локаль можно установить в /etc/locale.conf согласно инструкциям из настольной книги Gentoo:

ФАЙЛ /etc/locale.confНастройка системной локали

Загрузившись с systemd, можно использовать localectl для настройки локали и раскладок в консоли или X11. Чтобы изменить системную локаль, используйте следующую команду:

root #localectl set-locale LANG=<LOCALE>

Для изменения раскладки виртуальной консоли:

root #localectl set-keymap <KEYMAP>

И, наконец, установка раскладки в X11:

root #localectl set-x11-keymap <LAYOUT>

Если необходимо, то модель, вариант и опции можно определить так:

root #localectl set-x11-keymap <LAYOUT> <MODEL> <VARIANT> <OPTIONS>

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

root #env-update && source /etc/profile

Время и дата

Время, дату и временную зону можно установить с помощью timedatectl. Эта утилита так же позволит пользователям настроить синхронизацию без необходимости устанавливать net-misc/ntp или другого пакет, полагаясь только на средства systemd.

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

root #timedatectl --help

Автоматическая загрузка модулей

Автоматическая загрузка модулей настраивается с помощью разных файлов, или, скорее, каталога с файлами. Файлы настроек расположены в /etc/modules-load.d. При старте системы каждый такой файл со списком модулей будет загружен. Формат файла - это список модулей, каждый из которых начинается с новой строки, а сам файл может иметь любое имя, любой длины, но заканчивается на .conf. Загрузочные модули можно разделить на модули для программ, сервисов или иные пользовательские предпочтения. В качестве примера ниже файл virtualbox.conf содержит:

ФАЙЛ /etc/modules-load.d/virtualbox.confПример файла для модулей virtualbox

Automatic mounting of partitions at boot

Systemd is capable of automatically mounting various partitions to standardized location via systemd-gpt-auto-generator. This makes it possible to boot and automatically mount essential partitions without an fstab and without a root= paramter on the kernel command line. To use this capability, first systemd must be included in the initramfs, this is the case by default for initramfs images generated with Dracut on systems with systemd installed. And second, each partition must have the correct Partition Type GUID. A list of the most important GUIDs can be found in the systemd-gpt-auto-generator manual, the full list can be found on wikipedia.

To list the current Partition Type GUID of your partitions:


systemd-gpt-auto-generator can auto-mount partitions at the following locations, note that the correct GUID depends on the systems CPU architecture:

  • / SD_GPT_ROOT_....
  • /boot/ SD_GPT_ESP if no /efi/ and no XBOOTLDR partition, otherwise SD_GPT_XBOOTLDR
  • /efi/ SD_GPT_ESP if /efi/ is present on the root, if not then ESP is at /boot/
  • /home/ SD_GPT_HOME
  • /srv/ SD_GPT_SRV
  • /usr/ SD_GPT_USR_....
  • /var/ SD_GPT_VAR
  • /var/tmp/ SD_GPT_TMP
  • Swap SD_GPT_SWAP

Below is an example of the most basic partition layout consisting of one EFI System Partition and one x86-64 root partition.

NAME        LABEL    PARTLABEL            PARTTYPE                             PARTTYPENAME                 MOUNTPOINT
├─nvme1n1p1 ESP      EFI System Partition c12a7328-f81f-11d2-ba4b-00a0c93ec93b EFI System                   /boot
└─nvme1n1p2 Gentoo   Gentoo               4f68bce3-e8cd-4db1-96e7-fbcaf984b709 Linux root (x86-64)          /

The PARTTYPE for an EFI System Partition is c12a7328-f81f-11d2-ba4b-00a0c93ec93b, it will be mounted at either /efi/ or /boot/ depending on which of these mount points is available and on if there is also an Extended Boot Loader Partition (PARTTYPE=bc13c2ff-59e6-4262-a352-b275fd6f7172) present on this disk. The PARTTYPE for an x86-64 root parition is 4f68bce3-e8cd-4db1-96e7-fbcaf984b709.

If the Partition Type GUID is not correct it can be changed without data loss using a partitioning tool such as fdisk. Note that the system must be offline to change the patition types! A system rescue image, or secondary operating system, must be used to complete the following steps.

Open the disk with the to be changed partition types in fdisk, in this exameple /dev/nvme1n1 is used:

root #fdisk /dev/nvme1n1
Welcome to fdisk (util-linux 2.39.3).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Command (m for help):

List the current partition layout with the p command:

Command (m for help): p
Disk /dev/nvme1n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 970 EVO Plus 2TB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B25D5B33-4A10-F940-826C-3CB24ADC7D86
Device           Start        End    Sectors  Size Type
/dev/nvme1n1p1    2048    1052671    1050624  513M EFI System
/dev/nvme1n1p2 1052672 3907028991 3905976320  1.8T Linux root (x86-64)

Change the Partition Type GUID of any partition with the t command, followed by the number of the partition to be changed, and finally the alias for the desired partition type:

Command (m for help): t
Partition number (1,2, default 2): 2
Partition type or alias (type L to list all): L
Partition type or alias (type L to list all): 23
Changed type of partition 'Linux root (x86-64)' to 'Linux root (x86-64)'.

Repeat the above steps for any additional partitions of which the Partition Type GUID should be changed. Once completed, save the changes with the w command:

Command (m for help): w
systemd-gpt-auto-generator will only auto-mount partitions that reside on the same disk as the EFI System Partition that the system is being booted from.
Some tools may become confused if there is no root= parameter on the kernel command line at all. To placate such tools add root=/dev/gpt-auto-root to the kernel command line. This trick is also usefull if a swapfile on the root partition is used instead of a swap partition for hibernation, i.e. one may specify the resume target on the kernel command line as resume=/dev/gpt-auto-root resume_offset=xxxxxxxxx.


systemd is compatible with various network management tools.


See the systemd/systemd-networkd article for details on setting up a wired network on systemd systems.


See the systemd/systemd-resolved article for details on setting up address name resolution (DNS) on systemd systems.


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

root #nm-connection-editor

Если это не тот случай и сеть необходимо настроить через консоль, то попробуйте nmcli или следуйте руководству по настройке через nmtui:

root #nmtui

nmtui — это интерфейс на основе curses, запускаемый в консоли, который может помочь пользователям с настройкой сетевых интерфейсов.

For more details see the dedicated article.

Обработка лог-файлов

systemd имеет возможность обрабатывать лог-файлы без обращения к сторонним системам журналирования (таким как app-admin/syslog-ng или app-admin/rsyslog).

При желании сервис журналирования может быть настроен на передачу сообщений в такие внешние утилиты как sysklog или syslog-ng. См. man journald.conf, чтобы узнать, как настроить сервис systemd-journald для его приспособления под ситуативные нужды.

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

При использовании systemd-journald.service для журналирования, что обычно является значением по умолчанию для систем, использующих systemd, обычные пользователи при выполнении команды journalctl будут не иметь возможности просматривать системные журналы. Чтобы просматривать системные журналы от имени не root'а, пользователи должны быть в одной из трёх следующих групп: systemd-journal, adm или wheel. Самый простой способ разрешить обычному пользователю просматривать журналы – это использовать группу systemd-journal. Добавьте пользователя выполнением следующей команды, где larry – требуемое имя пользователя:

root #gpasswd --add larry systemd-journal
Теперь системные журналы могут быть прочитаны выполнением journalctl --system от имени пользователя(ей), добавленных в предыдущей команде.

Некоторые общие опции journalctl:

Параметры командной строки journalctl Результат
journalctl параметров Отобразить все записи, начиная с самых ранних.
-b, --boot Отобразить все записи с начала текущей загрузки.
-r, --reverse Отобразить сначала новейшие записи журнала (обратный хронологический порядок).
-f, --follow Отобразить некоторые последние записи и отобразить новые записи по мере их появления. Это похоже на запуск tail -f в утилитах текстового журналирования.
-p, --priority= Определить (минимальный) приоритет отображения сообщений, выбирая из: «emerg» (0), «alert» (1), «crit» (2), «err» (3), «warning» (4), «notice» (5), «info» (6), «debug» (7).
-S, --since=, -U, --until= Ограничить записи по времени. Формат «YYYY-MM-DD hh:mm:ss», либо «yesterday», «today» и «tomorrow».
-n, --lines= Ограничить количество записей.
-k, --dmesg Ограничиться только сообщениями от ядра.
-u, --unit= Ограничиться определенным юнитом systemd.
--system Просмотр журналов системный служб и ядра. По умолчанию это возможно только для суперпользователя. См. man journalctl, чтобы узнать, как предоставить обычным пользователям возможность читать системный журнал.

Для более детальной информации обратитесь к man journalctl.

/tmp теперь в tmpfs

Если какая-либо другая файловая система не настроена на монтирование к /tmp в /etc/fstab, то systemd смонтирует /tmp как tmpfs. Это значит, что она будет стираться при каждой загрузке и её размер будет ограничен 50% от объема физической оперативной памяти. Чтобы узнать, почему этот алгоритм предпочтителен и как его изменить, посетите API File Systems.

Настройка процесса загрузки

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

  • Опция командной строки ядра quiet влияет не только на вывод ядра, но и на systemd. Пока systemd настраивается на машине, отбросьте эту опцию, чтобы увидеть любые возникающие ошибки. После этого, верните обратно для «тихой» (и более быстрой) загрузки.
  • Даже с опцией командной строки ядра quiet, systemd еще может выводить свой статус через systemd.show_status=1.
  • Когда не используется опция командной строки ядра quiet, некоторые сообщения могут перезаписать старые в консоли. Это может быть обусловлено конфигурацией ядра (см. man 5 proc и /proc/sys/kernel/printk). Для корректировки вставьте параметр командной строки ядра loglevel=5 (и обновите значение в соответствии с предпочтением, к примеру, самое маленькое возможное значение равно 1).


Converting traditional home directories to systemd homed

See the systemd-homed subarticle.


В некоторых случаях систему необходимо перезагрузить, что бы дать systemd запуститься (в системном режиме). Будьте уверены, что прочитали весь этот документ и настроили systemd насколько это возможно до перезагрузки системы. Учтите, что journalctl можно пользоваться при не запущенном systemd, но systemctl ничего не сможет сделать без запущенного systemd. Закончите настройку сервисов (включение и запуск сервисов) после входа в систему с запущенным systemd.

Предустановка сервисов

Большинство сервисов отключены, когда systemd устанавливается в первый раз. Файл "предустановки" предоставлен и может быть использован, чтобы включить рациональный набор сервисов по умолчанию.

root #systemctl preset-all

Сервисы OpenRC

Несмотря на то, что изначально systemd предназначен для поддержки запуска старых init.d скриптов, эта поддержка не лучшим образом подходит к RC, таким как OpenRC, и полностью отключена на Gentoo. OpenRC осуществляет дополнительные меры, чтобы обеспечивать защиту от запуска init.d скриптов, когда OpenRC не был использован для загрузки (в противном случае результаты непредсказуемы).

Просмотр доступных сервисов

Все доступные сервисы могут быть представлены в виде списка через аргумент list-units для systemctl:

root #systemctl list-units
UNIT                               LOAD   ACTIVE SUB       DESCRIPTION
boot.automount                     loaded active waiting   EFI System Partition Automount
proc-sys-fs-binfmt_misc.automount  loaded active waiting   Arbitrary Executable File Formats File System Automount Point

Следующие окончания файлов представляют интерес:

Окончание Описание
.service Простые файлы, описывающие сервис (например, те, что запускают процесс-демона напрямую),
.socket «Прослушка» сокетов (как inetd).
.path Триггеры файловой системы для сервисов (запускают сервисы когда файлы изменены и т.д.).

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

root #systemctl --all --full

И, наконец, проверьте сервисы, которые не смогли запуститься:

root #systemctl --failed

Включение, отключение, запуск и остановка сервисов

Обычный способ включить сервис, это использовать следующую команду:

root #systemctl enable foo.service

Сервис также можно отключить:

root #systemctl disable foo.service

Эти команды включают сервисы, используя свое имя как цель по умолчанию (как это определенно в разделе "Install" в файле описывающий сервис). Однако, иногда такие файлы сериса не содержат данной информации или пользователи предпочитают использовать другое имя/цель.

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

root #systemctl start foo.service

Сервисы также могут быть остановлены:

root #systemctl stop foo.service

Services implementing ExecReload= can be commanded to reload their configuration without restarting itself:

root #systemctl reload foo.service

Установка пользовательских unit-файлов

Пользовательские unit-файлы могут быть размещены в /etc/systemd/system, где они распознаются после запуска systemctl daemon-reload:

root #systemctl daemon-reload

Путь /lib/systemd/system зарезервирован для файлов, описывающих сервис, которые установлены с помощью пакетного менеджера.

Пользовательская настройка unit-файлов

Когда необходимо внести только небольшие изменения в unit-файл, нет нужды в создании полной копии оригинального unit-файла в /etc/systemd/system. Переопределение настроек в управлении пакетами позволяет достигнуть этого перемещением файлов в каталог заканчивающийся на

  • .d после имени оригинального unit-файла (например apache2.d) в /etc/systemd/system/.

Both the drop-in directory and config file can be created using the systemctl edit utility or manually.

The editing utility can be invoked as:

root #systemctl edit apache2.service
ФАЙЛ /etc/systemd/system/apache2.service.d/mem-limit.confПример добавления/переопределения настроек в файле описывающий сервис

Перезагрузка systemd необходима для принятия изменений:

root #systemctl daemon-reload

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

root #systemctl restart apache2

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

root #systemctl show --property=MemoryLimit apache2

Включение сервиса под другим именем

Когда имя, определенное в Alias= раздела [Install] unit-файла, не соответствует ожиданиям и определение постоянного нового значения для этого через пользовательскую настройку не требуется, можно создать символическую ссылку в /etc/systemd/system/*.wants/. Имя директории *.wants может указывать на цель загрузки (target), либо на другой сервис, который будет зависеть от нового.

Например, чтобы установить mysqld.service как db.service в

root #ln -s /lib/systemd/system/mysqld.service /etc/systemd/system/

Для отключения сервиса просто удалите символическую ссылку:

root #unlink /etc/systemd/system/

Нативные сервисы

Некоторые пакеты Gentoo устанавливают systemd unit-файлы. Такие сервисы уже сразу можно включить. Общая информация о таких пакетах находится по адресу systemd eclass users list.

В следующей таблице приводится список сопоставление сервисов systemd и OpenRC:

Таблица миграции сервисов
Пакет Gentoo Сервис OpenRC systemd unit Примечание
sys-apps/openrc bootmisc systemd-tmpfiles-setup.service всегда включен, использует tmpfiles.d
consolefont systemd-vconsole-setup.service всегда включен, использует vconsole.conf
fsck fsck*.service неявно вытягивается через точки монтирования См. примечание bug #373219
hostname (встроено) /etc/hostname
hwclock See note always enabled as part of systemd (i.e. it is baked in and it is not a unit)
keymaps systemd-vconsole-setup.service always enabled, uses vconsole.conf
localmount actual units are created implicitly from /etc/fstab
modules systemd-modules-load.service всегда включено, использует /etc/modules-load.d/*.conf
procfs (встроено)
root remount-rootfs.service
savecache нет внутренняя функция OpenRC
swap actual units are created implicitly from /etc/fstab
sysctl systemd-sysctl.service sysctl.conf и sysctl.d/
sysfs (встроено)
termencoding systemd-vconsole-setup.service всегда включено, использует vconsole.conf
urandom systemd-random-seed-load.service
app-admin/rsyslog rsyslog rsyslog.service
app-admin/syslog-ng syslog-ng syslog-ng.service
media-sound/alsa-utils alsasound alsa-store.service (включено по умолчанию)
alsa-restore.socket (включено по умолчанию)
net-misc/dhcpcd dhcpcd dhcpcd.service
net-misc/netifrc net.* net@.service systemd wrapper for net.* scripts (comes with net-misc/netifrc)
netctl@.service net-misc/netctl is originally an Arch Linux tool.
NetworkManager.service For <networkmanager- : enable NetworkManager-dispatcher.service for dispatcher.d scripts to work.
Enable NetworkManager-wait-online.service to detect that the system has a working internet connection.
Disable all other managers (e.g., wicd, dhcpcd) and wpa_supplicant.
dhcpcd.service Предоставляется net-misc/dhcpcd
systemd.networkd.service Часть systemd
net-misc/openntpd ntpd ntpd.service
net-misc/openssh sshd sshd.service runs sshd as a daemon
sshd.socket runs sshd on a inetd-like basis (for each incoming connection)
net-wireless/wpa_supplicant wpa-supplicant wpa_supplicant.service D-Bus controlled daemon (e.g. for NetworkManager)
wpa_supplicant@.service interface-specific wpa_supplicant (used like wpa_supplicant@wlan0.service)
net-print/cups cupsd cups.service classic on-boot start up service
cups.socket socket and path activation (cups only started on-demand)
net-wireless/bluez bluetooth bluetooth.service
sys-apps/dbus dbus dbus.service
sys-apps/irqbalance irqbalance irqbalance.service supports daemon mode only
sys-apps/microcode-ctl microcode_ctl Configure microcode as a module to let it load the microcode itself. Go to "Processor type and features" -> "CPU microcode loading support" and remember to add the right option based on the system having an Intel or AMD processor.
sys-fs/udev udev udev.service
udev-mount (builtin) /dev is mounted as tmpfs
udev-postmount udev-trigger.service
sys-power/acpid acpid acpid.service Most of its functionality is done by systemd itself, so consider disabling this
x11-apps/xdm (xdm) xdm.service OpenRC uses common xdm init.d installed by x11-base/xorg-server. With systemd the corresponding unit file for each DM (gdm.service, kdm.service...) needs to be enabled.
net-firewall/iptables iptables iptables-store.service

Пользовательские сервисы

Можно управлять сервисами как экземплярами systemd для каждого пользователя. Это позволяет пользователям устанавливать свои собственные сервисы или таймеры.

Пользовательские модули могут быть расположены в нескольких местах. Самим пользователям разрешено размещать их в $XDG_CONFIG_HOME/systemd/user/. Установленные пакеты размещают их в /usr/lib/systemd/user/.

Пользовательские сервисы используют опцию --user systemctl. Например, для запуска пользовательской службы mpd:

user $systemctl --user start mpd

Сервисы таймеров

Начиная с версии 197, systemd поддерживает таймеры, делающие cron ненужным на системе с systemd. Начиная с версии 212 стал доступен постоянный сервис, который заменяет anacron. Постоянные таймеры запустятся при следующей возможности, если система была выключена, когда таймер был запланирован.

Следующий пример показывает, как создать простой таймер, который запустится в контексте пользователя. Он запустится даже если пользователь не вошел в систему. Каждый раз, когда сервис нуждается в таймере, файл сервиса активируется через таймер. Например:

ФАЙЛ ~/.config/systemd/user/backup-work.timerПример как запускать таймер каждый рабочий день
Description=daily backup work
OnCalendar=Mon-Fri *-*-* 11:30:00
ФАЙЛ ~/.config/systemd/user/backup-work.serviceПример триггера для запуска сервиса резервного копирования
Description=daily backup work

These unit files can be created either manually or using the systemctl edit utility:

user $systemctl edit --force --full --user backup-work.timer

When creating the unit files manually, the files are to be placed in the ~/.config/systemd/user directory. It may need to be created for the relevant user:

user $mkdir -p ~/.config/systemd/user

To have a timer run while the user is not logged in, be sure to enable lingering sessions:

user $loginctl enable-linger <username>

Во-первых, скажите systemd заново прочитать файлы описывающие сервис:

user $systemctl --user daemon-reload

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

user $systemctl --user start backup-work.service

Запустите и остановите таймер вручную:

user $systemctl --user start backup-work.timer
user $systemctl --user stop backup-work.timer

Наконец, включите таймер на каждый запуск системы:

user $systemctl --user enable backup-work.timer

Чтобы проверить последние результаты запущенного сервиса:

user $systemctl --user list-timers

Электронная почта о сбоях

Если сервис был запущен и дал сбой, то может быть отправлено электронное письмо с уведомлением об этом пользователя или администратора. Эта возможность осуществляется через строфу "OnFailure", определяющую действия на случай сбоя сервиса. Сбой распознается по ненулевому возвращенному коду от вызванного скрипта.

Для этого изменим скрипт как показано ниже:

ФАЙЛ ~/.config/systemd/user/backup-work.serviceПример триггера для запуска сервиса резервного копирования
Description=daily backup work

Для этого нужно установить сервис failure-email@.service, которую можно найти в kylemanna's systemd-utils repository.

Замена cron

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

Однако, cron также может быть запущен через скрипты в /etc/cron.daily и других директориях. Некоторые пакеты помещают скрипты туда, откуда они будут запускаться ежедневно. Это поведение может быть эмулировано с systemd, установив sys-process/systemd-cron. Далее, активируйте новую замену cron следующими командами:

root #systemctl enable
root #systemctl start

Устранение проблем

Slow shutdowns or reboot times due to running services

Occasionally a systemd system or user service will cause the system to greatly delay poweroff/shutdown or reboot operation due to systemd default wait times for the operation blocking service to time out.
To greatly speed up this operation, the default timeout values can be reduced at the expense of the service (potentially) not cleanly finishing a task. In order to be effective, both of the following configuration changes must be put into effect to shorten the default timeout system and user services.
ФАЙЛ /etc/systemd/system.conf.d/system.confReduce default timeout to 10s for hanging system services
ФАЙЛ ~/.config/systemd/user.confReduce default timeout to 10s for hanging user services

Буфер /dev/kmsg переполнен, некоторые сообщения потеряны

Когда при загрузке системы на экран выводится бесконечный цикл /dev/kmsg buffer overrun, some messages lost. Консольный экран входа никогда не появится пока система не перестанет зацикливаться в процессе загрузки.
В большинстве случаев такая ошибка возникает когда в ядре включена опция CONFIG_POWER_SUPPLY_DEBUG. Обходной путь состоит в отключении этой опции и пересборке нового ядра. Решение так же может быть найдено на форуме Gentoo. Для одного пользователя форума эта проблема была обнаружена при использовании I2C EEPROM на встроенной системе [1]. Решение заключалось в отключении опции ядра CONFIG_I2C_DEBUG_CORE.

Графические сессии, запущенные в разных местах

По умолчанию, systemd запускает процесс getty только тогда, когда он будет использоваться. Это приводит к тому, что некоторые менеджеры экрана (например GDM), используют оставшиеся TTY для открытия графических сессий по требованию, что в результате дает хаотичное размещение консолей и графических сессий в зависимости от порядка, в котором они используются.

Для того, чтобы придерживаться более классического поведения (т. е. консоли размещаются от tty1 до tty6, а графические сессии занимают оставшиеся TTY) принудительно включите getty:

root #systemctl enable getty@tty{2,3,4,5,6}.service


Когда переключаетесь с OpenRC на systemd и LVM необходим для правильного подключения системных томов, то включите LVM сервис:

root #systemctl enable lvm2-monitor.service

Пока это не нужно для корневого тома (если LVM интегрирован в initramfs), это может не работать для остальных LVM томов, если сервис запущен.



ЯДРО Включение поддержки systemd-bootchart
File systems  --->
	Pseudo filesystems --->
	[*] /proc file system support
Kernel hacking  --->
	[*] Kernel debugging
	[*] Collect scheduler debugging info
	[*] Collect scheduler statistics

Далее, включите systemd-bootchart.service:

root #systemctl enable systemd-bootchart

Все изменения будут помещены в bootchart-отчет в формате SVG файла, который размещается в /run/log/ после каждой загрузки. Его можно открыть в любом современном веб-браузере.

В качестве альтернативы systemd-bootchart, загрузку сервисов также можно визуализировать следующим образом:

root #systemd-analyze plot > plot.svg

syslog-ng для systemd

Не нужно добавлять unix-dgram('/dev/log'); в файл /etc/syslog-ng/syslog-ng.conf. Это приведет к сбою syslog-ng (как минимум в syslog-ng-3.7.2). Измените строку source src { ...; }; как упомянуто в статье syslog-ng:

ФАЙЛ /etc/syslog-ng/syslog-ng.conf
# для openrc
#source src { system(); internal(); };
# systemd
source src { systemd-journal(); internal(); };

Настройка sys-fs/cryptsetup

systemd не совсем коректно работает с /etc/conf.d/dmcrypt (см. bug #429966), так что его необходимо настроить в файле /etc/crypttab:

ФАЙЛ /etc/crypttabФайл настройки для зашифрованного блочного устройства
crypt-home UUID=c25dd0f3-ecdd-420e-99a8-0ff2eaf3f391 -

Убедитесь, что включен флаг cryptsetup для sys-apps/systemd. Это установит /lib/systemd/system-generators/systemd-cryptsetup-generator, который автоматически создаст сервис (cryptsetup@crypt-home.service для примера выше) для каждой записи при загрузке.

Проверьте unit, которые не смогли запуститься

Проверьте unit, которые не смогли запуститься с помощью команды:

root #systemctl --failed

Включение режима отладки

Для получения более детальной информации в /etc/systemd/system.conf настройте следующее:

ФАЙЛ /etc/systemd/system.conf

Или включите отладочную оболочку (debug-shell), которая откроет терминал на tty9. Этот терминал поможет отладить сервисы во время загрузки.

root #systemctl enable debug-shell.service

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

Пожалуйста, не забудьте отредактировать /etc/e4rat.conf, установив 'init' в /lib/systemd/systemd, иначе OpenRC по прежнему будет загружаться в качестве init.


С включенным grsecurity, systemd-networkd может выдать ошибку:

КОД Ошибка systemd-networkd
could not find udev device: Permission denied

Ошибка возникает из-за работающего под не root пользователем systemd-networkd, в связи с чем grsecurity отказывает в доступе к полной структуре /sys для таких пользователей. Для отключения этой опции отмените выбор CONFIG_GRKERNSEC_SYSFS_RESTRICT в настройке ядра.

У logind также есть некоторые тонкости с разрешением доступа, если включена опция CONFIG_GRKERNSEC_PROC; смотрите bug #472098.

shutdown -rF не форсирует fsck

Сервис systemd-fsck отвечает за запуск fsck, когда это необходимо. Он не обращает внимания на опцию -rF команды shutdown, но для него имеют значение следующие параметры загрузки ядра.

Параметр загрузки Поддерживаемые параметры Описание
fsck.mode auto
Контролирует режим операции. Значение по умолчанию — auto, в этом режиме проверяется, что все проверки ФС выполняются, когда это необходимо. force вызывает безусловную полную проверку ФС. skip пропускает любые проверки файловой системы. preen
Контролирует режим операции. Значение по умолчанию — preen, в этом режиме автоматически решаются все проблемы, избавиться от которых можно безопасно. yes ответит утвердительно на все запросы fsck, а no ответит на все запросы отрицательно.

Optional systemd binaries

Many optional systemd binaries can be built by setting certain use flags. An incomplete mapping of USE flag to binary is below.

USE flag Additional binary built
curl /lib/systemd/systemd-journal-upload
http /lib/systemd/systemd-journal-gatewayd

Смотрите также

Внешние ресурсы