Как скачать и установить Red Hat Enterprise Linux 8

Не так давно стала доступна для скачивания версия RHEL 8 Beta. Естественно, я не могу пройти мимо нее. Получить в пользование 30-дневную версию RHEL 8 можно по этой ссылке. По данной ссылке доступно два варианта скачивания: для тех кто не имеет платной подписки и для тех у кого она есть. У меня нет. И мой старый аккаунт почему-то не подтянулся, может он уже не активный. Пришлось регистрироваться.
Для начала необходимо иметь или завести (это можно сделать по ссылке выше) девелоперскую учетку. После заполнения всех форм на почту придет письмо для верификации аккаунта. И в ссылке выше выбираем какую версию мы хотим качать, соглашаемся на все и ждем. DVD-образ весит 6,5 Гб.
Пока качается, немного из гайда по установке:

  • Бету нельзя использовать в продакшене. Совсем.
  • У Беты нет гарантийной поддержки.
  • RHEL приветствуют отправку баг-репортов и открыты к взаимодействию.
  • Апгрейды Беты и до Беты не поддерживаются и не рекомендуются.

Образ скачан, я ставлю Red Hat 8 на виртуалке KVM. По своему-же мануалу, проблем не возникло)
Создаю виртуалку и запускаю установку:

virt-install \
--name=RHEL8 \
--ram=1024 --vcpus=1 \
--network bridge:br0 \
--disk path=/home/Lector/vm-images/vm_rhel.img,size=30 \
--cdrom /home/Lector/rhel-8.0-beta-1-x86_64-dvd.iso \
--os-variant=Linux

Если вы ставите RHEL с флэшки, то там иногда возникает проблема – инсталлятор не видит саму флэшку как установочный диск. Люди решают проблему как-то хитро и расово-верно, а я делаю все очень просто: после создания загрузочной флэшки кладу туда еще и сам iso. И потом его выбираю как источник установки.
Появляется привычное окно, жмем Install Red Hat Enterprise Linux 8.0

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

Получаем сообщение:
“Это предварительно выпущенное программное обеспечение, предназначенное только для разработки и тестирования. * Не * используйте это программное обеспечение для любой критической работы или в продакшене.
Нажав «I want to proceed», вы понимаете и принимаете риски, связанные с предварительно выпущенным ПО, которое вы намерены использовать только для целей тестирования и разработки и готовы сообщать о любых ошибках или проблемах, чтобы улучшить эту работу.
Если вы не понимаете или не принимаете эти риски, пожалуйста, выйдите из этой программы, выбрав «I want to exit» из вашей системы.”
Но мы то все понимаем и выбираем «I want to proceed».

Попадаем в окно настроек, которые можно сделать предварительно. Проблем с секцией LOCALIZATION возникнуть не должно ни у кого. Выбираем настройку клавиатуры, язык и установки даты/времени. Чтобы принять изменение, нажмите кнопку Done в левом верхнем углу.


Переходим к разделу SOFTWARE. В моем случае Installation Source – это local media. Секция Software Selection предлагает выбрать вариант установки. В левой части представлены варианты установки: Minimal Install (сделаю в следующем посте), Custom Operating System, Server и Workstation. Я хочу попробовать Workstation.
В правой части мы видим дополнительные пакеты, которые можно сразу установить. Не хочу греть голову ( это ж не минимал))) и выбираю все. Нажимаем Done.


Дальше секция SYSTEM, которой стоит уделить особое внимание. Состоит из 5ти пунктов:

    1. В разделе Installation Destination можно выбрать разбивку диска. Здесь мы выберем авторазбивку.
    2. KDUMP по умолчанию включен, так и оставлю. KDUMP это механизм аварийного дампа ядра. Когда происходит падение системы, он фиксирует содержимое системной памяти. Это может понадобиться для дальнейшего анализа причины сбоя. Когда KDUMP включен, он резервирует небольшой объем оперативной памяти. Эта часть памяти недоступна для основного ядра.
    3. Дальше Network & HostName. Я предпочитаю настроить и включить все сразу здесь. Переводим переключатель в положение on, жмем кнопку Configure. В моем случае настройки сети приходят по DHCP. Слева внизу можно сразу задать hostname.

    1. Далее идет Security Policy. Их можно вообще отключить, переведя переключатель “Apply security policy” в положение off. Либо щелкнуть на один из профилей и нажать кнопку “Select profile”. Применение политик безопасности не является обязательным. При применении какой-либо политики устанавливается пакет openscap-scanner, как инструмент для проверки соответствия и поиска уязвимостей. После завершения установки система будет отсканирована, отчет о результатах будет сохранен в директории /root/openscap_data .


В разделе System Purpose мы можем выбрать, как будем использовать нашу систему.

Итак. Если мы все выбрали, жмем кнопку Begin Installation. Пока система устанавливается, задаем пароль рута (Root password) и заводим себе пользователя (User Creation). Пользователя сразу можно сделать администратором. Это позволит использовать sudo.

После окончания установки нам станет доступна кнопка Reboot. Жмем и наслаждаемся тем же серым цветом загрузочного экрана, но теперь с цифрой 8.))))

После перезагрузки нас ждет приятный сюрприз. Ось сразу и сама предлагает принять лицензию. Уверенно жмем, что мы согласны и попадаем на логин.

Рабочий стол довольно веселый, стоит гном. Отвечаем на несколько вопросов о настройке и идем тестить нашу ось.

Глава 10. Управление сервисами в systemd. 10.6. Создание и изменение файлов юнитов в systemd. Часть 2

10.6.3. Конвертация SysV Init скриптов в файлы юнитов (Unit Files)

Прежде чем заняться преобразованием скрипта SysV (далее – init-скрпт) в файл юнита, убедитесь, что преобразование еще не было выполнено в другом месте. Все основные службы, установленные в Red Hat Enterprise Linux 7, поставляются со стандартными юнит-файлами, и то же самое относится ко многим сторонним программным пакетам.
Преобразование init-скрипта в юнит-файл требует анализа init-скрипта и извлечения из него необходимой информации. На основе полученных данных вы можете создать файл юнита, как описано в разделе 10.6.2 «Создание пользовательских файлов юнита». Поскольку init-скрипты могут сильно различаться в зависимости от типа сервиса, возможно вам потребуется использовать больше параметров конфигурации для конвертации, чем описано в этой главе. Обратите внимание, что некоторые уровни настройки, которые были доступны в init-скриптах, больше не поддерживаются модулями systemd, см. Раздел 10.1.2, «Изменения совместимости».
Большая часть информации, необходимой для конвертации, указана в заголовке скрипта. В следующем примере показан начальный раздел init-скрипта, используемого для запуска службы postfix в Red Hat Enterprise Linux 6 (пример файла юнита для postfix можно найти в предыдущей части):

#!/bin/bash
#
# postfix      Postfix Mail Transfer Agent
#
# chkconfig: 2345 80 30
# description: Postfix is a Mail Transport Agent, which is the program \
#              that moves mail from one machine to another.
# processname: master
# pidfile: /var/spool/postfix/pid/master.pid
# config: /etc/postfix/main.cf
# config: /etc/postfix/master.cf
 
### BEGIN INIT INFO
# Provides: postfix MTA
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop postfix
# Description: Postfix is a Mail Transport Agent, which is the program that 
#              moves mail from one machine to another.
### END INIT INFO

В приведенном выше примере обязательны только строки, начинающиеся с #chkconfig и #description, поэтому вы можете не найти остальных в разных init-файлах. Текст, заключенный между строками ### BEGIN INIT INFO и ### END INIT INFO, называется заголовком Linux Standard Base (LSB). Если LSB-заголовок указан, то он содержит директивы, определяющие описание службы, зависимости и уровни запуска (runlevels). Далее следует обзор аналитических задач, направленных на сбор данных, необходимых для нового юнит-файла. В качестве примера используется init-скрипт postfix, см. Итоговый файл модуля postfix в примере 10.17, «Файл юнита postfix.service».

Поиск описания сервиса

Найдите описание скрипта в строке, начинающейся с #description. Используйте это описание вместе с именем сервиса в опции Description секции [Unit] в файле юнита. Заголовок LSB может содержать аналогичные данные в строках #Short-Description и #Description.

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

Заголовок LSB может содержать несколько директив, которые формируют зависимости между сервисами. Большая часть может быть переведена в опции юнита systemd, см. Таблицу 10.12, «Параметры зависимостей из заголовка LSB».

Таблица 10.12, Параметры зависимостей из заголовка LSB
Опция LSB Описание Опция юнита
Provides Задает имя сервиса при загрузке, на которое можно ссылаться в других скриптах (с префиксом “$”). Сейчас это не требуется, т.к. юнит-файлы ссылаются на другие юнит-файлы по их именам.
Required-Start Содержит загрузочные имена необходимых сервисов. Т.е. это зависимости упорядочения, имена необходимых сервисов при переводе заменяются на имена юнит-файлов соответствующих сервисов или таргетов, которым они принадлежат. Например, в случае с postfix зависимость Required-Start: $network была переведена в зависимость After=network.target. After, Before
Should-Start Определяет более слабые зависимости, чем Required-Start. Неудачные зависимости Should-Start не влияют на запуск службы. After, Before
Required-Stop, Should-Stop Определяет негативные зависимости. Conflicts

Определение таргета для запуска сервиса

Строка, начинающаяся с #chkconfig, содержит три числовых значения. Для нас важно первое число, которым представлены уровни запуска по умолчанию для данного сервиса. Используйте Таблицу 10.6, «Сравнение уровней запуска SysV с таргетами systemd», чтобы перевести эти уровни выполнения в таргеты systemd. Затем перечислите эти таргеты в опции WantedBy в разделе [Install] файла юнита. Например, postfix ранее запускался на уровнях запуска 2, 3, 4 и 5, что соответствует таргетам multi-user.target и graphical.target в Red Hat Enterprise Linux 7. Обратите внимание, что graphical.target зависит от multiuser.target, поэтому нет необходимости указывать оба, как в примере 10.17, «Файл модуля postfix.service». Вы также можете найти информацию о дефолтных и запрещенных уровнях запуска в строках #Default-Start и #Default-Stop в заголовке LSB.
Два других значения, указанные в строке #chkconfig, представляют приоритеты запуска и завершения init-скрипта. Эти значения интерпретируются systemd, если он загружает init-скрипт, но нет эквивалентного юнит-файла.

Определение файлов, используемых сервисом

Init-скрипты требуют загрузки библиотеки функций из выделенной директории и позволяют импортировать файлы конфигурации, среды и PID файлы. Переменные среды указываются в строке, начинающейся с #config в заголовке скрипта и соответствует опции EnvironmentFile в файле юнита. Файл PID, указанный в init-скрипте в строке #pidfile импортируется в файл юнита с опцией PIDFile.
Ключевой информацией, которая не включена в заголовок скрипта, является путь к исполняемому файлу сервиса и, возможно, некоторые другие файлы, необходимые для сервиса. В предыдущих версиях Red Hat Enterprise Linux init-скрипты использовали оператор Bash case, чтобы определить поведение службы при действиях по умолчанию, таких как запуск, остановка или перезапуск, а также при выполнении определенных пользователем действий. Следующий фрагмент из init-скрипта postfix показывает блок кода, который должен быть выполнен при запуске сервиса.

conf_check() {
    [ -x /usr/sbin/postfix ] || exit 5
    [ -d /etc/postfix ] || exit 6
    [ -d /var/spool/postfix ] || exit 5
}
 
make_aliasesdb() {
	if [ "$(/usr/sbin/postconf -h alias_database)" == "hash:/etc/aliases" ]
	then
		# /etc/aliases.db might be used by other MTA, make sure nothing
		# has touched it since our last newaliases call
		[ /etc/aliases -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -ot /etc/aliases.db ] || return
		/usr/bin/newaliases
		touch -r /etc/aliases.db "$ALIASESDB_STAMP"
	else
		/usr/bin/newaliases
	fi
}
 
start() {
	[ "$EUID" != "0" ] && exit 4
	# Check that networking is up.
	[ ${NETWORKING} = "no" ] && exit 1
	conf_check
	# Start daemons.
	echo -n $"Starting postfix: "
	make_aliasesdb >/dev/null 2>&1
	[ -x $CHROOT_UPDATE ] && $CHROOT_UPDATE
	/usr/sbin/postfix start 2>/dev/null 1>&2 && success || failure $"$prog start"
	RETVAL=$?
	[ $RETVAL -eq 0 ] && touch $lockfile
        echo
	return $RETVAL
}

Init-скрипт позволяет указать пользовательские функции, здесь это conf_check() и make_aliasesdb(), которые вызываются из функционального блока start(). В приведенном выше коде упоминаются несколько внешних файлов и директорий: исполняемый файл основного сервиса /usr/sbin/postfix, директории конфигураций /etc/postfix/ и /var/spool/postfix/, а также директория /usr/sbin/postconf/.
Systemd поддерживает только предопределенные действия, но позволяет выполнять пользовательские исполняемые файлы с помощью ExecStart, ExecStartPre, ExecStartPost, ExecStop и ExecReload. В случае с postfix в RHEL 7, /usr/sbin/postfix выполняется вместе со вспомогательными скриптами при запуске сервиса. Посмотрите файл юнита postfix в Примере 10.17, «Файл модуля postfix.service».
Преобразование сложных скриптов требует понимания назначения каждого оператора в скрипте. Некоторые операторы относятся к конкретной версии операционной системы, поэтому вам не нужно переводить их. С другой стороны, в новой среде могут потребоваться некоторые корректировки, как в файле юнита, так и в исполняемом файле сервиса и вспомогательных файлах.

10.6.4. Изменение существующих файлов юнитов

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

  • Создайте директори. для дополнительных файлов конфигурации в /etc/systemd/system/unit.d/. Этот метод рекомендуется в большинстве случаев. Это позволяет расширить конфигурацию дополнительными функциональными возможностями, ссылаясь при этом на исходный файл юнита. Поэтому изменения в юните, поисходящие при обновлении пакета, применяются автоматически. См. Раздел «Расширение конфигурации юнита по умолчанию» для получения дополнительной информации.
  • Создайте копию файла юнита из /usr/lib/systemd/system/ в /etc/systemd/system/ и делайте изменения в ней. Копия переопределяет исходный файл, поэтому изменения, внесенные обновлением пакета, не применяются. Этот метод полезен для внесения значительных изменений в юниты, которые должны сохраняться независимо от обновлений пакета. Подробнее см. в разделе «Переопределение конфигурации модуля по умолчанию».

Чтобы вернуться к стандартной конфигурации юнита, просто удалите пользовательские файлы конфигурации в /etc/systemd/system/. Чтобы применить изменения к файлам юнита без перезагрузки системы, выполните:

systemctl daemon-reload

Опция daemon-reload перезагружает все файлы юнитов и воссоздает все дерево зависимостей для применения любых изменений в файлах юнитов. Того же результата можно добиться с помощью следующей команды:

init q

Также, если модифицированный юнит-файл принадлежит работающему сервису, необходимо перезапустить сам сервис для применения новых настроек:

systemctl restart name.service

Важно
Чтобы изменить свойства (такие как зависимости или тайм-ауты) сервиса, который обрабатывается init-скриптом SysV, не изменяйте сам init-скрипт. Вместо этого создайте системный файл конфигурации systemd для службы, как описано в разделе «Расширение конфигурации юнита по умолчанию» и в разделе «Переопределение конфигурации юнита по умолчанию». Затем управляйте этим сервисом так же, как обычным сервисом systemd.
Например, чтобы расширить конфигурацию сервиса network, не изменяйте init-файл /etc/rc.d/init.d/network. Вместо этого создайте новую директорию /etc/systemd/system/network.service.d/ и drop-in файл /etc/systemd/system/network.service.d/my_config.conf (прим. переводчика: для себя я определяю drop-in файлы как дополнительные конфиги. Система заглядывает в каталоги конфигурации и подбирает то, что там лежит). Затем поместите измененные значения в drop-in файл. Заметка: systemd знает сервис network как network.service, поэтому созданный каталог должен называться network.service.d.

Расширение конфигурации юнитов

Чтобы добавить дополнительные параметры конфигурации в файл юнита, сначала создайте директорию конфигурации в /etc/systemd/system/. Если вы расширяете юнит сервиса, выполните следующую команду от root:

mkdir /etc/systemd/system/name.service.d/

Замените name именем сервиса, который вы хотите расширить. Вышеуказанный синтаксис применяется ко всем типам юнитов.
Создайте файл конфигурации в директории, созданной на предыдущем шаге. Имя файла должно иметь суффикс .conf . Наберите:

touch /etc/systemd/system/name.service.d/config_name.conf

Замените config_name на имя файла конфигурации. Этот файл имеет структуру обычного файла юнита, поэтому все директивы должны быть указаны в соответствующих разделах, см. Раздел 10.6.1, «Понимание структуры файла юнита».
Например, чтобы добавить зависимость, создайте файл конфигурации со следующим содержимым:

[Unit]
Requires=new_dependency
After=new_dependency

Где new_dependency обозначает юнит, который помечен как зависимость. Другой пример файла конфигурации, который перезапускает сервис после того, как основной процесс завершится, с задержкой 30 секунд:

[Service]
Restart=always
RestartSec=30

Рекомендуется создавать небольшие файлы конфигураций, ориентированные на одну задачу. Такие файлы легко переместить или связать (создать линк) с каталогами конфигурации других сервисов.
Чтобы внесенные изменения вступили в силу, выполните от root:

systemctl daemon-reload
systemctl restart name.service

Пример 10.20. Расширение конфигурации httpd.service

Изменим юнит httpd.service так, чтобы при запуске Apache автоматически выполнялся shell-скрипт. Создайте каталог и файл конфигурации:

~]# mkdir /etc/systemd/system/httpd.service.d/
~]# touch /etc/systemd/system/httpd.service.d/custom_script.conf

Предположим, что /usr/local/bin/custom.sh – путь к скрипту, который вы хотите запустить вместе с Apache, вставьте следующий текст в файл custom_script.conf:

[Service]
ExecStartPost=/usr/local/bin/custom.sh

Чтобы принять изменения, выполните:

~]# systemctl daemon-reload
~]# systemctl restart httpd.service

Заметка

Файлы конфигурации из директорий /etc/systemd/system/ имеют приоритет над файлами юнитов в /usr/lib/systemd/system/. Следовательно, если файлы конфигурации содержат параметр, который может быть указан только один раз, например, Description или ExecStart, значение по умолчанию для этого параметра переопределяется. Обратите внимание, что в выходных данных команды systemd-delta, описанной в разделе «Мониторинг переопределенных юнитов», такие юниты всегда помечаются как [EXTENDED], хотя фактически некоторые параметры переопределяются.

Переопределение конфигурации юнита по умолчанию

Чтобы внести изменения в юнит, которые сохранятся после обновления пакета, сначала скопируйте файл в каталог /etc/systemd/system/. Для этого выполните от root:

cp /usr/lib/systemd/system/name.service /etc/systemd/system/name.service

Где name – имя сервиса, файл юнита которого вы хотите изменить. Этот синтаксис применим ко всем типам юнитов.
Откройте скопированный файл в текстовом редакторе и внесите желаемые изменения. Чтобы принять изменения, выполните от root:

systemctl daemon-reload
systemctl restart name.service

Пример 10.21. Изменение тайм-аута

Вы можете указать тайм-аут для каждой службы, чтобы предотвратить зависание системы из-за сбоя в работе службы. Обычно, тайм-аут установлен в 90 секунд для обычных сервисов и 300 секунд для SysV-совместимых сервисов.
Например, установим тайм-аут для httpd сервиса:

  1. Скопируйте юнит-файл httpd в директорию /etc/systemd/system/:
    cp /usr/lib/systemd/system/httpd.service /etc/systemd/system/httpd.service
  2. Откройте файл /etc/systemd/system/httpd.service и определите значение TimeoutStartUSec в секции [Service]:
    ...
    [Service]
    ...
    PrivateTmp=true
    TimeoutStartSec=10
     
    [Install]
    WantedBy=multi-user.target
    ...
  3. Перезагрузите демон systemd:
    systemctl daemon-reload
  4. Проверьте, что новый тайм-аут установлен:
    systemctl show httpd -p TimeoutStartUSec

Заметка
Чтобы сменить тайм-аут глобально, введите значение DefaultTimeoutStartSec в файл /etc/systemd/system.conf. Подробнее см. раздел 10.1, “Введение в systemd”.

Мониторинг переопределенных юнитов

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

systemd-delta

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

[EQUIVALENT] /etc/systemd/system/default.target → /usr/lib/systemd/system/default.target
[OVERRIDDEN] /etc/systemd/system/autofs.service → /usr/lib/systemd/system/autofs.service
 
--- /usr/lib/systemd/system/autofs.service      2014-10-16 21:30:39.000000000 -0400
+++ /etc/systemd/system/autofs.service  2014-11-21 10:00:58.513568275 -0500
@@ -8,7 +8,8 @@
 EnvironmentFile=-/etc/sysconfig/autofs
 ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid
 ExecReload=/usr/bin/kill -HUP $MAINPID
-TimeoutSec=180
+TimeoutSec=240
+Restart=Always
 
 [Install]
 WantedBy=multi-user.target
 
[MASKED]     /etc/systemd/system/cups.service → /usr/lib/systemd/system/cups.service
[EXTENDED]   /usr/lib/systemd/system/sssd.service → /etc/systemd/system/sssd.service.d/journal.conf
 
4 overridden configuration files found.

В таблице 10.13 «Типы различий systemd-delta» перечислены типы переопределений, которые можно увидеть в выводе systemd-delta. Обратите внимание, что если файл переопределен, systemd-delta по умолчанию отображает сводку изменений, аналогичную выводу команды diff.

Таблица 10.13, Типы различий systemd-delta
Опция LSB Описание
[MASKED] Замаскированные юниты. Как замаскировать юнит см. Раздел 10.2.7, “Удаление из автозагрузки”.
[EQUIVALENT] Неизмененные копии, которые переопределяют исходные файлы, но не отличаются по содержанию, как правило, это символические ссылки.
[REDIRECTED] Файлы, которые перенаправляют в другой файл.
[OVERRIDEN] Перезаписанные и измененные файлы.
[EXTENDED] Файлы, которые расширены файлами .conf в директории /etc/systemd/system/unit.d/.
[UNCHANGED] Неизмененные файлы, отображаются при использовании опции --type=unchanged.

Рекомендуется запускать systemd-delta после обновления системы, чтобы проверить, есть ли какие-либо обновления для юнитов по умолчанию, которые в настоящее время переопределяются пользовательской конфигурацией. Также можно ограничить вывод только определенным типом различий. Например, чтобы просмотреть только переопределенные блоки [OVERRIDEN], выполните:

systemd-delta --type=overridden

10.6.5. Работа с юнитами, созданными из шаблона (Instantiated Units)

Можно создать несколько экземпляров из одного файла конфигурации шаблона во время выполнения. Символ «@» используется для обозначения шаблона и ассоциации юнита с ним. Instantiated units могут быть запущены из другого файла юнита (с использованием параметров Requires или Wants) или с помощью команды systemctl start. Instantiated service units именуются следующим образом:

template_name@instance_name.service

Где template_name – имя файла конфигурации шаблона. Замените instance_name именем экземпляра юнита. Несколько экземпляров могут указывать на один и тот же файл шаблона с параметрами конфигурации, общими для всех экземпляров юнита. Имя шаблона юнита имеет вид:

unit_name@.service

Например, следующая настройка Wants в файле юнита:

Wants=getty@ttyA.service,getty@ttyB.service

сначала выполняет поиск для заданных сервисных юнитов. Если таких юнитов не найдено, часть между “@” и суффиксом типа игнорируется, и systemd ищет файл getty@.service, считывает из него конфигурацию и запускает сервисы.
Подстановочные знаки, называемые спецификаторами единиц, могут использоваться в любом файле конфигурации юнитов. Спецификаторы юнита заменяют определенные параметры модуля и интерпретируются во время выполнения. В таблице 10.14 «Важные спецификаторы юнитов» перечислены полезные для юнитов-шаблонов спецификаторы юнитов.

Таблица 10.14, Важные спецификаторы юнитов
Спецификатор Значение Описание
%n Полное имя юнита Полное имя юнита, включая суффикс. %N имеет то же значение, но также заменяет запрещенные символы на коды ASCII.
%p Префикс Имя юнита без суффикса типа. Для созданных экземпляров юнитов %p обозначает часть имени юнита перед символом «@».
%i Instance name Имя экземпляра Это часть имени экземпляра юнита между символом «@» и суффиксом типа. %I имеет то же значение, но также заменяет запрещенные символы на коды ASCII.
%H Host name Имя хоста Имя хоста работающей системы в момент загрузки конфигурации юнита.
%t Runtime directory Represents the runtime directory, which is either /run for the root user, or the value of the XDG_RUNTIME_DIR variable for unprivileged users.
Представляет собой runtime-директорию, которая либо /run для пользователя root, либо значение из переменной окружения XDG_RUNTIME_DIR для непривилегированных пользователей.

Полный список спецификаторов см. в мануале systemd.unit(5).

Например, шаблон getty@.service содержит следующие директивы:

[Unit]
Description=Getty on %I
...
[Service]
ExecStart=-/sbin/agetty --noclear %I $TERM
...

Когда создаются экземпляры getty@ttyA.service и getty@ttyB.service из вышеприведенного шаблона, Description = преобразуется в Getty on ttyA и Getty on ttyB.

10.7. Additional Resources – этот раздел я не вижу смысла переводить, так как он просто содержит ссылки на дополнительные источники информации. Но оставлю его тут)

Глава 10. Управление сервисами в systemd. 10.6. Создание и изменение файлов юнитов в systemd. Часть 1

Файл юнита содержит директивы, которые описывают юнит и определяют его поведение. Некоторые команды systemctl работают с файлами юнитов в фоновом режиме. Чтобы произвести более детальную настройку, системный администратор должен отредактировать или создать файл юнита вручную. В Таблице 10.2 «Расположение файлов юнитов systemd» перечислены три основных директории, в которых хранятся файлы юнитов системы. Каталог /etc/systemd/system/ зарезервирован для юнитов, созданных или настроенных системным администратором.
Имена файлов имеют следующий вид:

unit_name.type_extension

где unit_name – имя юнита, type_extension – его тип. Полный список типов юнитов см. в Таблице 10.1, “Доступные типы юнитов systemd”. Например, обычно в системе существуют юниты sshd.service и sshd.socket.
Файлы юнитов могут быть дополнены каталогом дополнительных конфигурационных файлов. Например, чтобы добавить пользовательскую конфигурацию sshd.service, создайте файл sshd.service.d/custom.conf и добавьте в него дополнительные директивы. Больше информации о директориях конфигурации см. в разделе 10.6.4, “Изменение существующих файлов юнитов”.
Кроме того, могут быть созданы директории sshd.service.wants/ и sshd.service.requires/. Эти директории содержат символические ссылки (симлинки) на файлы юнитов сервиса sshd. Симлинки либо автоматически создаются во время установки в соответствии с параметрами в секции [Install] файла юнита (см. таблицу 10.11, “Важные опции секции [Install]), либо во время выполнения в соответствии с параметрами секции [Unit] (см. таблицу 10.9, “Важные опции секции [Unit]). Также можно создать эти директории и симлинки вручную.
Многие опции юнит-файла могут быть установлены с использованием так называемых спецификаторов юнитов – подстановочных строк, которые динамически заменяются параметрами юнита при загрузке файла юнита. Это позволяет создавать общие файлы юнитов, которые служат шаблонами для генерации конкретных экземпляров. См. раздел 10.6.5, “Работа с юнитами, созданными из шаблона (Instantiated Units)” для получения дополнительной информации.

10.6.1 Понимание структуры файла юнита

Файлы юнитов обычно содержат три секции:

Таблица 10.9, Важные параметры секции [Unit]
Опция[a] Описание
Description Информативное описание юнита. Эта информация отображается, например, в выводе команды systemctl status
Documentation Предоставляет список URI (Uniform Resource Identifier — унифицированный идентификатор ресурса), ссылающийся на документацию для юнита.
After[b] Определяет порядок запуска юнитов. Юнит запускается только после того, как активированы юниты, указанные в After. В отличие от Requires, After не активирует явно определенные юниты. Опция Before имеет противоположную функциональность After.
Requires Настраивает зависимости от других юнитов. Юниты, перечисленные в разделе Requires, активируются вместе с юнитом. Если какой-либо из необходимых юнитов не запускается, юнит не активируется.
Wants Настраивает более слабые зависимости, чем Requires. Если какой-либо из перечисленных юнитов не запускается, он не влияет на активацию данного юнита. Это рекомендуемый способ установки зависимостей пользовательских юнитов.
Conflicts Настраивает отрицательные зависимости, противоположные Requires.
[a] Полный список параметров, настраиваемых в разделе [Unit], см. в man systemd.unit (5).
[b] В большинстве случаев, достаточно устновить зависимости с опциями After и Before. Если вы также установили зависимость от требований Wants (рекомендуется) или Requires, зависимости последовательности все еще должны быть определены. Связано это с тем, что зависимости упорядочения и требований работают раздельно.

Таблица 10.10, Важные параметры секции [Service]
Опция[a] Описание
Type Настраивает тип запуска юнита, который влияет на функциональность ExecStart и связанных с ним опций. Возможные значения:

  • simple – Значение по умолчанию. Процесс стартующий с ExecStart, является основным процессом сервиса.
  • forking – Процесс, запущенный с ExecStart, порождает дочерний процесс, который становится основным процессом сервиса. После завершения запуска родительский процесс завершается.
  • oneshot – Этот тип похож на simple, но процесс завершается до запуска последующих юнитов.
  • dbus – Этот тип похож на simple, но последующие юниты запускаются только после того, как основной процесс получает D-Bus имя.
  • notify – похож на simple, но последующие юниты запускаются только после отправвки уведомления посредством функции sd_notify().
  • idle – похож на simple, фактическое выполнение сервиса задерживается до завершения всех заданий, что позволяет избежать смешивания потока вывода состояния с выводом сервиса.
ExecStart Указывает команды или сценарии, которые должны выполняться при запуске юнита. ExecStartPre и ExecStartPost определяют пользовательские команды, которые должны выполняться до и после ExecStart. Type=oneshot позволяет указать несколько пользовательских команд, которые затем выполняются последовательно.
ExecStop Определяет команды или скрипты, которые должны выполняться при остановке юнита.
ExecReload Определяет команды или скрипты, которые должны выполняться при перезагрузке юнита.
Restart Если эта опция включена, сервис перезапускается после завершения его процесса, за исключением чистой остановки командой systemctl.
RemainAfterExit Если установлено значение True, сервис считается активным, даже когда все его процессы завершены. Значение по умолчанию – False. Эта опция особенно полезна, если используется Type=oneshot.
[a] Полный список параметров, настраиваемых в разделе [Service], см. в man systemd.service (5).

Таблица 10.11, Важные параметры секции [Install]
Опция[a] Описание
Alias Предоставляет список дополнительных имен для юнита, разделенных побелами. Большая часть команд systemctl, за исключением systemctl enable, может использовать алиасы вместо фактического имени юнита.
RequiredBy Список юнитов, которые зависят от этого юнита. Когда этот юнит включен, юниты перечисленные в RequiredBy gain a Require dependency on the unit.
WantedBy Список юнитов, которые слабо зависят от этого юнита. Когда этот юнит включен, юниты перечисленные в WantedBy gain a Want dependency on the unit.
Also Указывает список юнитов, которые будут установлены или удалены вместе с юнитом.
DefaultInstance Ограничена конкретным юнитом, эта опция определяет экземпляр по умолчанию для которого активирован юнит. См. раздел 10.6.5, “Работа с юнитами, созданными из шаблона (Instantiated Units)”
[a] Полный список параметров, настраиваемых в разделе [Install], см. в man systemd.unit (5).

Пример 10.17, «Юнит-файл postfix.service» показывает пример сервисного юнита, установленного в системе. Кроме того, параметры файла юнита могут быть определены таким образом, чтобы обеспечить динамическое создание юнитов, как описано в Разделе 10.6.5 «Работа с юнитами, созданными из шаблона (Instantiated Units)».

Пример 10.17. Юнит-файл postfix.service

Ниже представлено содержание файла юнита /usr/lib/systemd/system/postifix.service:

[Unit]
Description=Postfix Mail Transport Agent
After=syslog.target network.target
Conflicts=sendmail.service exim.service
 
[Service]
Type=forking
PIDFile=/var/spool/postfix/pid/master.pid
EnvironmentFile=-/etc/sysconfig/network
ExecStartPre=-/usr/libexec/postfix/aliasesdb
ExecStartPre=-/usr/libexec/postfix/chroot-update
ExecStart=/usr/sbin/postfix start
ExecReload=/usr/sbin/postfix reload
ExecStop=/usr/sbin/postfix stop
 
[Install]
WantedBy=multi-user.target

Секция [Unit] описывает сервис, определяет зависимости, а также конфликтующие юниты. В [Service] указывается последовательность пользовательских скриптов, которые должны выполняться во время активации юнита, остановки и перезагрузки. EnvironmentFile указывает на место, где определены переменные среды для сервиса, PIDFile задает PID для основного процесса сервиса. Наконец, в разделе [Install] перечислены зависимости.

10.6.2. Создание пользовательских файлов юнитов

Существует несколько способов создания файлов юнитов с нуля: вы можете запустить собственны демон, создать второй экземпляр какой-либо существующей службы (как в примере 10.19, «Создание второго экземпляра службы sshd») или импортировать скрипт инициализации SysV (см. в разделе 10.6.3, «Преобразование сценариев инициализации SysV в файлы модулей»). С другой стороны, если вы намереваетесь просто изменить или расширить поведение существующего юнита, используйте инструкции из раздела 10.6.4, «Изменение существующих файлов модуля». Следующая процедура описывает общий процесс создания пользовательского юнита:

  1. Подготовьте исполняемый файл с помощью пользовательского сервиса. Это может быть пользовательский скрипт или исполняемый файл, предоставленный поставщиком программного обеспечения. При необходимости подготовьте PID-файл для хранения постоянного PID основного процесса пользовательской службы. Также можно включить файлы среды для хранения переменных оболочки для сервиса. (It is also possible to include environment files to store shell variables for the service.) Убедитесь, что исходный скрипт является исполняемым (выполнив команду chmod a+x) и не является интерактивным.
  2. Создайте файл юнита в директории /etc/systemd/system/ и убедитесь, что он имеет корректные права доступа. Выполните от рута:
    touch /etc/systemd/system/name.service
    chmod 664 /etc/systemd/system/name.service

    Замените name имененм сервиса, который должен быть создан. Обратите внимание, что файл не должен быть исполняемым.

  3. Откройте файл name.service, созданный на предыдущем шаге и добавьте параметры конфигурации сервиса. Существует множество вариантов, которые можно использовать в зависимости от типа службы, которую вы хотите создать, см. раздел 10.6.1, «Понимание структуры файлов модуля». Ниже приведен пример конфигурации модуля для сетевой службы:
    [Unit]
    Description=service_description
    After=network.target
     
    [Service]
    ExecStart=path_to_executable
    Type=forking
    PIDFile=path_to_pidfile
     
    [Install]
    WantedBy=default.target

    Где:

    • service_description – это информативное описание, которое отображается в логах (журналах) и в выводе команды systemctl status.
    • настройка After обеспечивает запуск службы только после запуска сети. Добавьте добавьте другие службы или таргеты, разделив их пробелами.
    • path_to_executable устанавливает путь к исполняемому файлу службы.
    • Type=forking используется для демонов, которые делают системный вызов fork. Основной процесс службы создается с PID, указанным в path_to_pidfile. Другие типы запуска можно посмотреть в таблице 10.10, «Важные опции [Service]».
    • WantedBy указывает таргет или таргеты, под которыми служба должна быть запущена. Представьте, что это замена старой концепции ранлевелов, подробнее см. Раздел 10.3, «Работа с таргетами systemd».
  4. Сообщите systemd о существовании нового файла с именем name.service выполнив следующую команду от root:
    systemctl daemon-reload
    systemctl start name.service

    Предупреждение!
    Всегда выполняйте команду systemctl daemon-reload после создания нового файла юнита или модификации существующего. В противном случае, команды systemctl start или systemctl enable могут завершиться ошибкой из-за несоответствия между состоянием systemd и актуальными файлами юнитов на диске.
    Юнит name.service теперь может управляться как любой другой сервис с помощью команд, описанных в разделе 10.2 “Управление системными сервисами”.

Пример 10.18. Создание файла emacs.service

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

  1. Создайте юнит-файл в директории /etc/systemd/system/ удостоверьтесь, что он имеет корректные права доступа. Выполните как root:
    ~]# touch /etc/systemd/system/emacs.service
    ~]# chmod 664 /etc/systemd/system/emacs.service
  2. Добавьте в файл следующее содержимое:
    [Unit]
    Description=Emacs: the extensible, self-documenting text editor
     
    [Service]
    Type=forking
    ExecStart=/usr/bin/emacs --daemon
    ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)"
    Environment=SSH_AUTH_SOCK=%t/keyring/ssh
    Restart=always
     
    [Install]
    WantedBy=default.target

    В приведенной выше конфигурации исполняемый файл /usr/bin/emacs запускается как демон при запуске службы. Переменная среды SSH_AUTH_SOCK задается с помощью спецификатора “%t”, который stands for the runtime directory. Сервис также перезапускает процесс emacs, если он неожиданно завершает работу.

  3. Выполните следующие команды, чтобы перезагрузить конфигурацию и запустить пользовательский сервис:
    ~]# systemctl daemon-reload
    ~]# systemctl start emacs.service

Поскольку редактор теперь зарегистрирован как сервис systemd, вы можете использовать все стандартные команды systemctl. Например, запустите systemctl status emacs для отображения статуса редактора или systemctl enable emacs для автоматического запуска редактора при загрузке системы.

Пример 10.19. Создание второго экземпляра службы sshd

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

  1. Создайте копию файла sshd_config file который будет использоваться вторым демоном:
    ~]# cp /etc/ssh/sshd{,-second}_config
  2. Отредактируйте ранее созданный файл sshd-second_config, ччтобы назначить другой порт и и PID-файл для второго демона:
    Port 22220
    PidFile /var/run/sshd-second.pid

    См. мануал sshd_config(5) (man sshd_config) для получения дополнительной информации об опция Port и PidFile. Удостоверьтесь, что порт, который вы выбрали, не используется другим сервисом. PID-файл не должен существовать до запуска сервиса, он генерируется автоматически при старте сервиса.

  3. Создайте копию файла юнита systemd для сервиса sshd:
    ~]# cp /usr/lib/systemd/system/sshd.service /etc/systemd/system/sshd-second.service
  4. После измените файл sshd-second.service следующим образом:
    • Измените опцию Description:
      Description=OpenSSH server second instance daemon
    • Добавьте sshd.service к службам, указанным в опции After, чтобы второй экземпляр запускался только после того, как первый уже запущен:
      After=syslog.target network.target auditd.service sshd.service
    • Первый экземпляр sshd включает генерацию ключа, поэтому удалите строку ExecStartPre=/usr/sbin/sshd-keygen.
    • Добавьте параметр -f /etc/ssh/sshd-second_config к команде запуска sshd, чтобы использовать альтеративный файл конфигурации:
      ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
    • После вышеуказанных изменений sshd-second.service должен выглядеть следующим образом:
      [Unit]
      Description=OpenSSH server second instance daemon
      After=syslog.target network.target auditd.service sshd.service
       
      [Service]
      EnvironmentFile=/etc/sysconfig/sshd
      ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
      ExecReload=/bin/kill -HUP $MAINPID
      KillMode=process
      Restart=on-failure
      RestartSec=42s
       
      [Install]
      WantedBy=multi-user.target
  5. Если вы используете SELinux, добавьте порт для второго экземпляра sshd в порты для SSH, иначе привязка у порту для второго экземпляра будет отклонена:
    ~]# semanage port -a -t ssh_port_t -p tcp 22220
  6. Добавьте сервис sshd-second.service в автоматическую загрузку:
    ~]# systemctl enable sshd-second.service

    Проверьте, запущен ли sshd-second.service, с помощью команды systemctl status. Также проверьте, доступен ли порт, подключившись к сервису:

    ~]~]$ ssh -p 22220 user@server

    Если используется файрвол, убедитесь что он настроен таким образом, чтобы разрешать подключение второго экземпляра sshd по данному порту.

Для получения информации о том, как правильно выбрать таргет, для упорядочения и зависимостей пользовательских юнитов, см следующие статьи:
How to write a service unit file which enforces that particular services have to be started
How to decide what dependencies a systemd service unit definition should have
Дополнительная информация с реальными примерами упорядочения и зависимостей для файлов юнитов доступна в следующей статье: Is there any useful information about writing unit files?
Как установить ограничения для служб, запускаемых systemd, см. в Статье базы знаний Red Hat How to set limits for services in RHEL 7 and systemd. Эти ограничения должны быть установлены в файле юнита службы. Обратите внимание, что systemd игнорирует ограничения, установленные в файлах конфигурации /etc/security/limits.conf и /etc/security/limits.d/*.conf. Ограничения, определенные в этих файлах, устанавливаются PAM при запуске сеанса входа в систему, но демоны, запущенные systemd, не используют сеансы входа в PAM.

Глава 10. Управление сервисами в systemd. 10.5 Управление systemd на удаленной машине

В дополнение к управлению системой systemd и диспетчером служб локально, утилита systemctl также позволяет вам взаимодействовать с systemd, работающим на удаленной машине по протоколу SSH. При условии, что служба sshd на удаленном компьютере запущена, вы можете подключиться к этому компьютеру, запустив команду systemctl с опцией -host или -H:

systemctl --host user_name@host_name command

Замените user_name именем удаленного пользователя, host_name именем удаленного хоста (или ip) и введите любую из команд systemctl из описанных в предыдущих главах. Обратите внимание, что на удаленном компьютере должен быть сконфигурирован ssh, чтобы разрешить удаленный доступ выбранному пользователю. Для получения информации о том, как настроить SSH-сервер, см. Chapter 12, OpenSSH.

Пример 10.16. Удаленное управление

Чтобы войти на удаленный компьютер server-01.example.com как пользователь root и определить текущий статус сервиса httpd.service, выполните следующую команду:

~]$ systemctl -H root@server-01.example.com status httpd.service
>>>>>>> systemd unit files -- update
root@server-01.example.com's password:
httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled)
   Active: active (running) since Fri 2013-11-01 13:58:56 CET; 2h 48min ago
 Main PID: 649
   Status: "Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec"
   CGroup: /system.slice/httpd.service

Глава 10. Управление сервисами в systemd. 10.4 Выключение, приостановка и спящий режим

В RHEL 7 утилита systemctl заменила команды управления питанием из предыдущих версий дистрибутива. Команды, представленные в Таблице 10.8 “Сопоставление команд управления питанием с systemctl” также доступны в системе, но, по-возможности, рекомендуется использовать systemctl.

Таблица 10.7 Сопоставление команд управления питанием с systemctl
Старая команда Новая команда Описание
halt systemctl halt Останавливает систему
poweroff systemctl poweroff Выключает систему
reboot systemctl reboot Перезагружает систему
pm-suspend systemctl suspend Приостанавливает систему
pm-hibernate systemctl hibernate Отправляет систему в спящий режим
pm-suspend-hybrid systemctl hybrid-sleep Отправляет в спящий режим и приостанавливает систему

10.4.1.Выключение системы

Утилита systemctl предоставляет команды для выключения системы, однако традиционная команда shutdown также поддерживается. Хотя команда shutdown вызовет утилиту systemctl для выключения системы, она все же имеет преимущество т.к. поддерживает аргумент времени.
Это особенно полезно для планового обслуживания и дает пользователю время отреагировать на предупреждение системы о завершении работы. Преимуществом также является возможность отмены выключения.

Использование команды systemctl

Чтобы отключить систему и выключить машину введите в командной строке от root’а:

systemctl poweroff

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

systemctl halt

По умолчанию каждая из этих команд заставляет systemd отправлять информационное сообщение всем пользователям, которые вошли в систему. Чтобы предотвратить отправку этого сообщения, запустите выбранную команду с опцией –no-wall, например:

systemctl --no-wall poweroff

Использование команды shutdown

Чтобы отключить систему и выключить машину в определенное время, выполните от root’а:

shutdown --poweroff hh:mm

Где hh:mm – время в 24-часовом формате. Ща 5 минут до выключения системы содается файл /run/nologin, который предоствращает вход в систему. При использовании аргумента времени можно добавить сообщение.
Чтобы выключить и остановить систему с задержкой, без отключения компьютера, используйте следующую команду от root:

shutdown --halt +m

Где +m время задержки до выключения в минутах. Вместо now можно также использовать +0. The now keyword is an alias for +0.
Ожидание завершения работы может быть отменено от root’а следующим образом:

shutdown -c

См. страницу мануала shutdown(8) (man shutdown), чтобы посмотреть дополнительные параметры команды.

10.4.2. Перезагрузка системы

Чтобы перезапустить систему, наберите от root’а:

systemctl reboot

По умолчанию эта команда заставляет systemd отправлять информационное сообщение пользователям, которые залогинены в системе. Чтобы предовратить отправку сообщения, выполните эту команду с опцией --no-wall:

systemctl --no-wall reboot

10.4.3. Приостановка системы

Чтобы приостановить систему, наберите от root’а:

systemctl suspend

Эта команда сохраняет состояние системы в ОЗУ и отключает большую часть устройств, за исключением модуля ОЗУ. Когда вы снова включаете машину, система восстанавливает свое состояние из ОЗУ без повторной загрузки. Поскольку состояние системы сохраняется в ОЗУ, а не на жестком диске, восстановление системы из режима приостановки значительно быстрее, чем восстановление ее из спящего режима, но, как следствие, состояние приостановленной системы также уязвимо для отключения питания.

10.4.4. Спящий режим

Чтобы отправить систему в спящий режим:

systemctl hibernate

Эта команда сохраняет состояние системы на жесткий диск и отключает машину. Когда вы включаете машину снова, система восстанавливает это состояние из сохраненных данных без повторной загрузки. Поскольку состояние системы сохраняется на жестком диске, а не в ОЗУ, машине не требуется электроэнергия для ОЗУ, но, как следствие, восстановление системы из спящего режима происходит значительно медленнее, чем восстановление из режима ожидания.
Чтобы отправить в спящий режим и приостановить систему, выполните от root’а:

systemctl hybrid-sleep

(Прим.пер. – я так понимаю, это своего рода перестраховка. Система приостановлена, но при сбое питания у нас есть сохраненное состояние системы на харде.)

Глава 10. Управление сервисами в systemd. 10.3 Работа с таргетами в systemd

Предыдущие версии RHEL, которые распространялись с SysV init или Upstart, включали предопределенный набор уровней запуска (ранлевелов), которые представляли собой конкретные режимы работы. Ранлевелы нумеровались от 0 до 6 и определяли набор системных сервисов, которые запускались когда системный администратор запускал определенный ранлевел. В RHEL7 концепция уровней запуска была заменена таргетами systemd.
Таргеты systemd представлены таргет-юнитами. Файлы этих юнитов имеют расширение .target и их предназначение в том, чтобы объединить другие юниты systemd в цепочку зависимостей. Например, юнит graphical.target, который используется для запуска графического интерфейса, запускает такие сервисы как GNOME Display Manager (gdm.service) или Accounts Service (accounts-daemon.service), а также активирует таргет multi-user.target. Аналогично, юнит multi-user.target запускает другие важные системные сервисы, такие как NetworkManager (NetworkManager.service) или D-Bus (dbus.service), и активирует другой таргет с именем basic.target.
RHEL распространяется с несколькими предопределенными таргетами, которые похожи на стандартные уровни выполнения предыдущих релизов системы. По соображениям совместимости он также предоставляет псевдонимы для этих таргетов, которые непосредственно отображают их на уровни запуска SysV. В таблице 10.6 «Сравнение уровней запуска SysV с таргетами systemd» представлен полный список уровней запуска SysV и соответствующих им таргетов.

Таблица 10.6 Сравнение уровней запуска SysV init с таргетами systemd
Ранлевел Таргет Описание
0 runlevel0.target, poweroff.target Завершение работы и отключение системы
1 runlevel1.target, rescue.target Оболочка восстановления
2 runlevel2.target, multi-user.target Многопользовательская система без графоболочки
3 runlevel3.target, multi-user.target Многопользовательская система без графоболочки
4 runlevel4.target, multi-user.target Многопользовательская система без графоболочки
5 runlevel5.target, graphical.target Многопользовательская система с графоболочкой
6 runlevel6.target, reboot.target Выключение и перезагрузка системы

Чтобы просмотреть, изменить или настроить таргеты systemd, используйте утилиту systemctl, как описано в таблице 10.7, «Сравнение команд SysV init с systemctl» и в следующих разделах. Команды runlevel и telinit по-прежнему доступны в системе и работают должным образом, но включены только по соображениям совместимости и их следует избегать.

Таблица 10.7 Сравнение команд SysV init с таргетами systemd
Старая команда Новая команда Описание
runlevel systemctl list-units –type target Список загруженных таргетов
telinit
runlevel
systemctl isolate name.target Смена текущего таргета

10.3.1. Просмотр таргета по умолчанию

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

systemctl get-default

Эта команда читает симлинк, расположенный в /etc/systemd/system/default.target, и отображает результат. Для получения информации о том, как сменить таргет по умолчанию см. в разделе 10.3.3, “Смена таргета по умолчанию”. Для получения списка всех загруженных таргетов см. раздел 10.3.2,”Просмотр текущих таргетов”.
Пример 10.10. Просмотр таргета по умолчанию
Чтобы отобразить таргет по умолчанию, выполните:

~]$ systemctl get-default
graphical.target

10.3.2. Просмотр текущего таргета

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

systemctl list-units --type target

Для каждого таргета эта команда отображает полное имя (UNIT), за ним следует примечание загружен ли юнит (LOAD), высокоуровневый (ACTIVE) и низкоуровневый (SUB) статус юнита, и краткое описание (DESCRIPTION).
По умолчанию команда systemctl list-units отображает только активные юниты. Если вы хотите просмотреть список всех загруженных юнитов независимо от их состояния, запустите эту команду с флагом --all или -a:

systemctl list-units --type target --all

Как сменить текущий таргет см. в разделе 10.3.4, “Смена текущего таргета”.

Пример 10.11. Просмотр текщего таргета

~]$ systemctl list-units --type target
UNIT                  LOAD   ACTIVE SUB    DESCRIPTION
basic.target          loaded active active Basic System
cryptsetup.target     loaded active active Encrypted Volumes
getty.target          loaded active active Login Prompts
graphical.target      loaded active active Graphical Interface
local-fs-pre.target   loaded active active Local File Systems (Pre)
local-fs.target       loaded active active Local File Systems
multi-user.target     loaded active active Multi-User System
network.target        loaded active active Network
paths.target          loaded active active Paths
remote-fs.target      loaded active active Remote File Systems
sockets.target        loaded active active Sockets
sound.target          loaded active active Sound Card
spice-vdagentd.target loaded active active Agent daemon for Spice guests
swap.target           loaded active active Swap
sysinit.target        loaded active active System Initialization
time-sync.target      loaded active active System Time Synchronized
timers.target         loaded active active Timers
 
LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
 
17 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

10.3.3. Смена таргета по умолчанию

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

systemctl set-default name.target

Замените name на имя таргета, который вы хотите сделать дефолтным (например, multi-user). Эта команда заменяет файл /etc/systemd/system/default.target символической ссылкой на /usr/lib/systemd/system/name.target, где name это имя таргета, который вы хотите использовать. Как сменить текущий таргет см. в разделе 10.3.4, “Смена текущего таргета”. Как посмотреть информацию о текущем таргете, см. раздел 10.3.2,”Просмотр текущих таргетов”.

Пример 10.12. Смена таргета по умолчанию

Чтобы скофигурировать систему для использования multi-user.target по умолчанию, выполните от root:

~]# systemctl set-default multi-user.target
rm '/etc/systemd/system/default.target'
ln -s '/usr/lib/systemd/system/multi-user.target' '/etc/systemd/system/default.target'

10.3.4. Смена текущего таргета

Чтобы сменить таргет в текущей сессии, наберите от root:

systemctl isolate name.target

Замените name на имя таргета, который вы хотите использовать (например, multi-user). Эта команда запускает таргет с именем name и немедленно останавливает все остальные. Как сменить таргет по умолчанию см. раздел 10.3.3, “Смена таргета по умолчанию”. Как просмотреть список загруженных таргетов см. в разделе 10.3.2,”Просмотр текущих таргетов”.

Пример 10.13. Смена текущего таргета

Чтобы выключить графический интерфейс и сменить его на multi-user.target в текущей сессии, запустите от root:

~]# systemctl isolate multi-user.target

10.3.5. Переход в режим восстановления

Режим восстановления предоставляет однопользовательскую среду и позволяет восстановить систему в ситуациях, когда система не может завершить обычный процесс загрузки. В режиме восстановления система пытается смонтировать все локальные файловые системы и запустить некоторые системные сервисы, но не активирует сетевые интерфейсы и не позволяет одновременно входить нескольким пользователям в систему. В RHEL 7 режим восстановления эквивалентен однопользовательскому режиму и требует ввода рутового пароля.
Смена текущего таргета и переход в режим восстановления в текущей сессии (от root):

systemctl rescue

Этак команда похожа на systemctl isolate rescue.target, но она также отправляет информационное сообщение всем пользователям, которые в настоящее время вошли в систему. Чтобы система не отправляла сообщение, запустите команду с опцией --no-wall:

systemctl --no-wall rescue

Пример 10.14. Переход в режим восстановления

~]# systemctl rescue
Broadcast message from root@localhost on pts/0 (Fri 2013-10-25 18:23:15 CEST):
 
The system is going down to rescue mode NOW!

10.3.6. Переход в аварийный режим

Аварийный режим предоставляет минимально возможную среду и позволяет восстановить систему даже тогда, когда она не может загрузиться в режим восстановления. Система монтирует root file system только для чтения и запускает только несколько основных сервисов, не пытается подключить другие файловые системы и не активирует сеть. В RHEL 7 аварийный режим требует ввода пароля root’а.
Чтобы сменить текущий таргет на аварийный режим, введите от root’а:

systemctl emergency

Эта команда похожа на systemctl isolate emergency.target, но она дополнительно отправляет сообщение всем пользователям, которые в настоящее время вошли в систему. Чтобы система не отправляла сообщение, запустите команду с опцией --no-wall:

systemctl --no-wall emergency

Пример 10.15. Переход в аварийный режим
Чтобы перейти в аварийный режим с отправкой сообщения всем пользователям, запустите от root’а:

~]# systemctl --no-wall emergency

Виртуализация. KVM на CentOS 7 (RHEL 7), простой мануал.

Устанавливаем и настраиваем KVM на CentOS 7. Я поставлю на виртуалку Astra Linux. Хочу просто ознакомиться с этим дистрибутивом.

Сначала посмотрим, поддерживает ли наш проц виртуализацию:

grep -E 'svm|vmx' /proc/cpuinfo

Вывод команды не должен быть пустым.
Установим несколько пакетов, которые не входят в базовую установку RHEL и CentOS 7.

sudo yum -y install qemu-kvm libvirt libvirt-python libguestfs-tools virt-install virt-viewer

Включим сервис libvirtd и добавим его в загрузку (от рута).

sudo systemctl enable libvirtd && systemctl start libvirtd

Сеть. Мы создадим мост br0. Для этого создаем файлик ifcfg-br0.

sudo nano /etc/sysconfig/network-scripts/ifcfg-br0

Примерно следующего содержания:

DEVICE="br0"
BOOTPROTO="dhcp"
ONBOOT="yes"
TYPE="Bridge"
DELAY="0"

А сейчас внимание! После того, как мы создали новый бридж (br0 в нашем случае), для него в файле /etc/qemu-kvm/bridge.conf (в других дистрибутивах может быть несколько иной путь, типа /etc/qemu/bridge.conf) необходимо добавить строку:

allow br0

, а иначе можно получить что-то вроде: “failed to retrieve file descriptor for interface: transport endpoint is not connected” при попытке создания новой гостевой ОС. И мост не поднимется.
Теперь включим перенаправление (network forwarding), в файле /etc/sysctl.conf добавим строку:

net.ipv4.ip_forward = 1

Перечитаем файл и перезапустим сеть:

sudo sysctl -p /etc/sysctl.conf
sudo systemctl restart NetworkManager

Диски и SELinux.
Я буду хранить диски виртуалок в домашнем каталоге, в директории ~/vm-images.

mkdir ~/vm-images

Для управления SELinux установим policycoreutils-python (содержит утилиту semanage):

sudo yum -y install policycoreutils-python

Установим контекст для нашей директории. От рута выполняем:

sudo semanage fcontext --add -t virt_image_t '/home/Lector/vm-images(/.*)?'

Проверим, что контекст создан (1я строка наша):

sudo semanage fcontext -l | grep virt_image_t
/home/Lector/vm-images(/.*)?                        all files          system_u:object_r:virt_image_t:s0 
/var/lib/imagefactory/images(/.*)?                 all files          system_u:object_r:virt_image_t:s0 
/var/lib/libvirt/images(/.*)?                      all files          system_u:object_r:virt_image_t:s0

Далее выполяем:

sudo restorecon -R -v /home/Lector/vm-images

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

sudo ls -aZ /home/Lector/vm-images
drwxrwxr-x. Lector Lector unconfined_u:object_r:virt_image_t:s0 .
drwx------. Lector Lector unconfined_u:object_r:user_home_dir_t:s0 ..

Перейдем к созданию виртуальной машины.
Но сначала обязательно проверьте кому принадлежат права на vm-images и при надобности, смените владельца (chown -R user:user some/dir/vm-images). Я создаю машины от имени своего пользователя. (Проверьте, что интерфейс br0 появился)

virt-install \
> --name=astra \
> --ram=1024 \
> --vcpus=1 \
> --network bridge:br0 \
> --disk path=~Lector/vm-images/vmastra.img,size=20 \
> --cdrom ~Lector/Downloads/orel_live_2015030601.iso \
> --os-variant=Linux

Здесь, в принципе, все ясно, но все же:

--name - имя новой машины
--ram - оператива
--vcpus - колическтво виртуальных процессоров
--network - сеть
--disk - место хранения жесткого диска для нашей машины, size - размер в Гб
--cdrom - указываем где лежит файл образа, с которого ставим
--os-variant - тип оси

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

Глава 10. Управление сервисами в systemd. 10.2 Управление системными сервисами

Предыдущие версии RHEL, которые поставлялись с системой инициализации SysV или Upstart, использовали скрипты инициализации, расположенные в директории/etc/rc.d/init.d/. Эти скрипты как правило были написаны на Bash и позволяли системному администратору контролировать состояние служб и демонов в системе. В Red Hat Enterprise Linux 7 эти скрипты были заменены сервисными юнитами.
Сервисные юниты имеют расширение .service (прим.пер. – в этом разделе мы будем говорить именно про эти сервисы)и делают то же, что делали init-скрипты. Чтобы просмотреть, запустить, остановить, перезапустить, включить или отключить системные службы, используйте команду systemctl, как описано в Таблице 10.3,”Сравнение утилиты service с systemd” и Таблице 10.4, “Сравнение утилиты chkconfig с systemctl”, а также далее в этом разделе. Команды service и chkconfig по прежнему доступны в системе и работают как ожидалось, но включены в системе только по соображениям совместимости и их следует избегать (прим.пер. – хотя бы потому, что юниты systemd все равно имеют больший приоритет).

Таблица 10.3. Сравнение утилиты service с systemd
service systemctl Описание
service name start systemctl start name.service Запуск сервиса
service name stop systemctl stop name.service Остановка сервиса
service name restart systemctl restart name.service Рестарт сервиса
service name condrestart systemctl try-restart name.service Рестарт сервиса только если он запущен
service name reload systemctl reload name.service Перезагрузка конфигурации
service name status systemctl status name.service
systemctl is-active name.service
Проверяет запущен ли сервис
service –status-all systemctl list-units –type service –all Отображает статус всех сервисов

Таблица 10.4, Сравнение утилиты chkconfig с systemctl
chkconfig systemctl Description
chkconfig name on systemctl enable name.service Включает сервис в автозагрузку
chkconfig name off systemctl disable name.service Удаляет сервис из автозагрузки
chkconfig –list name systemctl status name.service
systemctl is-enabled name.service
Проверяет активирован ли сервис
chkconfig –list systemctl list-unit-files –type service Выводит список всех сервисов и проверяет активированы ли они
chkconfig –list systemctl list-dependencies –after Просмотр списка сервисов, которые должны запускаться до указанного юнита
chkconfig –list systemctl list-dependencies –before Просмотр списка сервисов, которые должны запускаться после указанного юнита

Определение сервисных юнитов

Для ясности все примеры команд в этом разделе содержат полное имя юнита с расширением .service, например:

~]# systemctl stop nfs-server.service

При желании расширение файла может быть опущено, и в этом случае утилита systemctl предполагает, что аргумент является юнитом типа .service. Данная команда эквивалентна предыдущей команде:

~]# systemctl stop nfs-server

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

~]# systemctl show nfs-server.service -p Names

Поведение systemctl в среде chroot

Если вы смените корневой каталог с помощью команды chroot, многие команды systemctl перестанут выполняться. Причина в том, что systemd и пользователь, который выполнил chroot имеют не одинаковое представление о файловой системе. Такое случается, например, при вызове systemctl из файла kickstart.
Исключением являются команды systemctl enable и systemctl disable. Этим командам не нужна запущенная система и они не влияют на запущенные процессы, но влияют на файлы юнитов. Поэтому вы можете запускать эти команды даже в chroot. Например, добавим в автозагрузку сервис httpd в каталоге /srv/website1/:

~]# chroot /srv/website1
~]# systemctl enable httpd.service
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service, pointing to /usr/lib/systemd/system/httpd.service.

10.2.1. Списки сервисов

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

systemctl list-units --type service

Для каждого юнит-файла эта команда отображает полное имя (UNIT), за ним следует примечание, загружен ли файл юнита (LOAD), высокоуровневый (ACTIVE) и низкоуровневый (SUB) статус юнита, и краткое описание (DESCRIPTION). По умолчанию команда systemctl list-units отображает только активные юниты. Если вы хотите просмотреть все загруженные юниты независимо от их статуса, запустите эту команду с опцией –all или -a:

systemctl list-units --type service --all

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

systemctl list-unit-files --type service

Для каждого сервисного юнита эта команда отображает полное имя (UNIT FILE) и информацию о том, активирован ли юнит (STATE). Информацию о том, как определить статус отдельных сервисов, см. в разделе 10.2.2 “Отображение статуса сервиса”.

Пример 10.1. Списки сервисов

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

~]$ systemctl list-units --type service
UNIT                           LOAD   ACTIVE SUB     DESCRIPTION
abrt-ccpp.service              loaded active exited  Install ABRT coredump hook
abrt-oops.service              loaded active running ABRT kernel log watcher
abrt-vmcore.service            loaded active exited  Harvest vmcores for ABRT
abrt-xorg.service              loaded active running ABRT Xorg log watcher
abrtd.service                  loaded active running ABRT Automated Bug Reporting Tool
...
systemd-vconsole-setup.service loaded active exited  Setup Virtual Console
tog-pegasus.service            loaded active running OpenPegasus CIM Server
 
LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.
 
46 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'

Список установленных сервисов, показывающий включены ли они в автозагрузку:

~]$ systemctl list-unit-files --type service
UNIT FILE                                   STATE
abrt-ccpp.service                           enabled
abrt-oops.service                           enabled
abrt-vmcore.service                         enabled
abrt-xorg.service                           enabled
abrtd.service                               enabled
...
wpa_supplicant.service                      disabled
ypbind.service                              disabled
 
208 unit files listed.

10.2.2. Отображение статуса сервиса

Чтобы отобразить подробную информацию о юните сервиса, соответствующему системному сервису, введите следующую команду:

systemctl status name.service

Замените name на имя юнита сервиса, который вы хотите проверить (например, gdm). Эта команда отобразит имя выбранного юнита, затем краткое описание, одно или несколько полей из описанных в Таблице 10.5, “Доступная информация о юнитах сервисов”. А если вы выполните команду под пользователем root, то также увидите последние записи из лога.

Таблица 10.5. Доступная информация о юнитах сервисов
Поле Описание
Loaded Информация о том, загружен ли юнит сервиса, абсолютный путь к файлу юнита, включен ли в автозагрузку
Active Информация о том, запущен ли юнит сервиса и отметка о времени
Main PID PID соответствующей системной службы и далее ее имя.
Status Дополнительная информация о соответствующем системном сервисе.
Process Дополнительная информация о связанных процессах.
CGroup Дополнительная информация о связанных контрольных группах (cgroups).

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

systemctl is-active name.service

Аналогично, чтобы определить активирован ли определенный юнит сервиса, введите:

systemctl is-enabled name.service

Обратите внимание, что systemctl is-active и systemctl is-enabled возвращают статус 0 если данный юнит сервиса запущен или включен в автозагрузку. Информацию о том, как просмотреть все загруженные юниты сервисов см. в разделе 10.2.1. Списки сервисов.

Пример 10.2. Отображение статуса сервиса

Юнит сервиса для GNOME Display Manager называется gdm.service. Чтобы определить текущий статус этого сервиса, введите следующую команду:

~]# systemctl status gdm.service
gdm.service - GNOME Display Manager
   Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled)
   Active: active (running) since Thu 2013-10-17 17:31:23 CEST; 5min ago
 Main PID: 1029 (gdm)
   CGroup: /system.slice/gdm.service
           ├─1029 /usr/sbin/gdm
           ├─1037 /usr/libexec/gdm-simple-slave --display-id /org/gno...
           └─1047 /usr/bin/Xorg :0 -background none -verbose -auth /r...
 
Oct 17 17:31:23 localhost systemd[1]: Started GNOME Display Manager.

Пример 10.3. Отображение сервисов, которые запускаются до старта выбранного сервиса

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

~]# systemctl list-dependencies --after gdm.service
gdm.service
├─dbus.socket
├─getty@tty1.service
├─livesys.service
├─plymouth-quit.service
├─system.slice
├─systemd-journald.socket
├─systemd-user-sessions.service
└─basic.target
[output truncated]

Пример 10.4. Отображение сервисов, которые запускаются после старта выбранного сервиса

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

~]# systemctl list-dependencies --before gdm.service
gdm.service
├─dracut-shutdown.service
├─graphical.target
│ ├─systemd-readahead-done.service
│ ├─systemd-readahead-done.timer
│ └─systemd-update-utmp-runlevel.service
└─shutdown.target
  ├─systemd-reboot.service
  └─final.target
    └─systemd-reboot.service

10.2.3. Запуск сервиса

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

systemctl start name.service

Замените name именем сервиса, который вы хотите запустить (например, gdm). Эта команда запустит выбранный сервис в текущей сессии. Как включить юнит в автозагрузку см. в Разделе 10.2.6, “Включение сервиса в автозагрузку”. Как определить статус юнита см. в Разделе 10.2.2, “Отображение статуса сервиса”.

Пример 10.5. Запуск сервиса

Юнит сервиса Apache HTTP Server имеет имя httpd.service. Чтобы запустить демон httpd в текущей сессии, выполните следующую команду от root:

~]# systemctl start httpd.service

10.2.4. Остановка сервиса

Чтобы остановить юнит сервиса и соответствующий системный сервис, введите следующую команду от root:

systemctl stop name.service

Замените name на имя сервиса, который вы хотите остановить (например, bluetooth). Эта команда останавливает выбранный юнит сервиса в текущей сессии. О том как отключить запуск юнита при старте системы см. в Разделе 10.2.7 “Удаление сервиса из автозагрузки”. Как определить статус юнита см. в Разделе 10.2.2 “Отображение статуса сервиса”.

Пример 10.6. Остановка сервиса
Сервисный юнит для демона bluetoothd имеет имя bluetooth.service. Чтобы оставновить демон bluetoothd в текущей сессии, введите следующую команду от root:

~]# systemctl stop bluetooth.service

10.2.5. Перезапуск сервиса

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

systemctl restart name.service

Замените name на имя сервиса, который вы хотите перезапустить (например, httpd). Эта команда остановит выбранный сервис и сразу запустит его снова. Если выбранный сервис не запущен, то эта команда запустит его. Чтобы systemd перезапустила сервис только в том случае, если он уже запущен, выполните следующую команду от root:

systemctl try-restart name.service

Некоторые сервисы позволяют перезагрузить конфигурацию без прерывания их выполнения. Для этого выполните от root:

systemctl reload name.service

Обратите внимание, что системные сервисы, которые не поддерживают эту функцию, полностью игнорируют эту команду. Для удобства команда systemctl также поддерживает команды reload-or-restart и reload-or-try-restart, которые перезапускают такие службы. Как определить статус юнита см. в Разделе 10.2.2 “Отображение статуса сервиса”.

Пример 10.7. Перезапуск сервиса

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

~]# systemctl reload httpd.service

10.2.6. Включение сервиса в автозагрузку

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

systemctl enable name.service

Замените name на имя сервиса, который вы хотите включить в автозагрузку (например, httpd). Эта команда считывает раздел [Install] выбранного юнита и создает соответствующие символические ссылки (далее – симлинки) на файл /usr/lib/systemd/system/name.service из директории /etc/systemd/system/ и его поддиректорий. Однако, эта команда не перезаписывает уже существующие симлинки. Если вы хотите заново создать симлинки, используйте следующую команду от root:

systemctl reenable name.service

Эта команда убирает юнит из автозагрузки и тут же добавляет его снова. Чтобы получить информацию о том, включен ли юнит в автозагрузку см. в Разделе 10.2.2, “Отображение статуса сервиса”. Как запустить сервис в текущей сессии см. в Разделе 10.2.3,”Запуск сервиса”.

Пример 10.8. Включение сервиса в автозагрузку

Чтобы включить Apache HTTP Server в автозагрузку, введите следующую команду от root:

~]# systemctl enable httpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

10.2.7. Удаление из автозагрузки

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

systemctl disable name.service

Замените name на имя сервиса, который вы хотите отключить (например, bluetooth). Эта команда считывает раздел [Install] выбранного юнита и удалаяет соответствующий симлинк на файл /usr/lib/systemd/system/name.service из директории /etc/systemd/system/ и ее поддиректорий. Также. вы можете замаскировать юнит для предотвращения его запуска вручную или другим сервисом. Для этого выполните от root следующую команду:

systemctl mask name.service

Эта команда заменит файл /etc/systemd/system/name.service симлинком на /dev/null, что сделает сервис фактически недоступным для systemd. Чтобы отменить это действие, выполните от root:

systemctl unmask name.service

Чтобы получить информацию о том, включен ли юнит в автозагрузку см. Раздел 10.2.2, “Отображение статуса сервиса”. Как остановить юнит в текущей сессии см. в Разделе 10.2.4, “Остановка сервиса”.

Пример 10.9. Удаление из автозагрузки

Пример 10.6, “Остановка сервиса” показывает как остановить сервис в текущей сессии. Чтобы предотвратить запуск сервиса во время загрузки, наберите следующую команду от root:

~]# systemctl disable bluetooth.service
Removed symlink /etc/systemd/system/bluetooth.target.wants/bluetooth.service.
Removed symlink /etc/systemd/system/dbus-org.bluez.service.

10.2.8. Запуск конфликтующего сервиса

В systemd существуют положительные и отрицательные зависимости между сервисами. Для запуска сервиса может потребоваться запуск (положительная зависимость) или остановка (отрицательная зависимость) других сервисов.
Когда вы пытаетесь запустить сервис, systemd автоматически разрешает все зависимости. Обратите внимание, что это делается без явного уведомления пользователя. Если вы запустили сервис, а потом пытаетесь запустить сервис с отрицательной зависимостью, первый сервис будет автоматически остановлен.
Например, если вы запускаете сервис postfix, а потом пробуете запустить sendmail, systemd сначала остановит postfix, потому что эти сервисы конфликтуют и не могут работать на одном и том же порту одновременно.

Глава 10. Управление сервисами в systemd. 10.1. Вступление.

(Перевод документации по RHEL)
Systemd – это системный и сервисный менеджер для операционных систем Linux. Он сохраняет обратную совместимость со сценариями инициализации SysV и предоставляет ряд функций, таких как параллельный запуск системных служб во время загрузки, активация демонов по требованию или логика управления сервисами на основе зависимостей. В Red Hat Enterprise Linux 7 systemd заменяет Upstart как систему инициализации по умолчанию. Читать далее «Глава 10. Управление сервисами в systemd. 10.1. Вступление.»