Systemd – менеджер системы и сервисов в операционной системе Linux. При разработке eго стремились спроектировать обратно совместимым со скриптами инициализации SysV init и предоставить полезные функции, такие, как параллельный запуск системных сервисов во время загрузки, активацию демонов по требованию, поддержку снепшотов состояния системы и логику управления сервисами, основанную на зависимостях. В CentOS 7 systemd заменяет Upstart как систему инициализации по умолчанию.


В этой статье мы рассмотрим процесс управления сервисами в systemd для пользователя CentOS 7. Эти знания будут полезны и в других дистрибутивах, ведь systemd уже давно используется в Fedora и планируется в Ubuntu 14.10 и Debian 8. Хорошо это или нет — оставим за кадром.



CentOS 7 Systemd Infobox

В процессе чтения статьи вы можете попробовать systemd на классических VPS и облачных VPS от Infobox. Мы стремимся своевременно добавлять поддержку современных ОС, чтобы вы могли использовать последние технологии для более эффективной работы. Сама идея написания статьи родилась после очередного вопроса пользователей об использовании сервисов в CentOS 7. Типичный вопрос: «Как добавить мой сервис в автозагрузку CentOS 7?». На этот и другие вопросы постараемся дать ответ в этой статье.



Введение

Systemd приносит концепцию юнитов systemd. Юниты представлены конфигурационными файлами, размещенными в одной из директорий:

  • /usr/lib/systemd/system/ – юниты из установленных пакетов RPM.
  • /run/systemd/system/ — юниты, созданные в рантайме. Этот каталог приоритетнее каталога с установленными юнитами из пакетов.
  • /etc/systemd/system/ — юниты, созданные и управляемые системным администратором. Этот каталог приоритетнее каталога юнитов, созданных в рантайме.


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



Типы юнитов systemd:

  • .service – системный сервис
  • .target — группа юнитов systemd
  • .automount – точка автомонтирования файловой системы
  • .device – файл устройства, распознанного ядром
  • .mount – точка монтирования файловой системы
  • .path – файл или директория в файловой системе
  • .scope – процесс, созданный извне
  • .slice – группа иерархически организованных юнитов, управляющая системными процессами
  • .snapshot – сохраненное состояние менеджера systemd
  • .socket – сокет межпроцессного взаимодействия
  • .swap – Свап-устройство или свап-файл (файл подкачки)
  • .timer – таймер systemd


Основные функции systemd в CentOS 7

  • Активация, основанная на сокетах. Во время загрузки systemd прослушивает сокеты для всех системных сервисов, поддерживает этот тип активации и передает сокеты этим сервисам сразу после старта сервисов. Это позволяет systemd не только запускать сервисы параллельно, но также дает возможность перезапускать сервисы без потери любых отправленных им сообщений, пока сервисы были недоступны. Соответствующий сокет остается доступным и все сообщения выстраиваются в очередь.
  • Активация, основанная на D-Bus. Системные сервисы, использующие D–Bus для межпроцессного взаимодействия, могут быть запущены по требованию, когда клиентское приложение пытается связаться с ними.
  • Активация, основанная на девайсах. Системные сервисы, поддерживающие активацию, основанную на девайсах, могут быть запущены, когда определенный тип оборудования подключается или становится доступным.
  • Активация, основанная на путях. Системные сервисы могут поддерживать этот вид активации, если изменяется состояние папки или директории.
  • Снепшоты системных состояний. Система может сохранять состояние всех юнитов и восстанавливать предыдущее состояние системы.
  • Управление точками монтирования и автомонтирования. Systemd отслеживает и управляет точками монтирования и автомонтирования.
  • Агрессивная параллелизация Systemd запускает системные сервисы параллельно из-за использования активации, основанной на сокетах. В комбинации с сервисами, поддерживающими активацию по требованию, параллельная активация значительно уменьшает время загрузки системы.
  • Транзакционная логика активации юнитов. До активации и деактивации юнитов systemd вычисляет их зависимости, создает временную транзакцию и проверяет целостность этой транзакции. Если транзакция нецелостная, systemd автоматически пытается исправить ее и удалить не требующиеся задания из нее до формирования сообщения об ошибке.
  • Обратная совместимость с инициализацией SysV. SystemD полностью поддерживает скрипты инициализации SysV, как описано в спецификации Linux Standard Base (LSB), что упрощает переход на systemd.


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

В предыдущих версиях CentOS использовалась SysV или Upstart. Скрипты инициализации располагались в директории /etc/rc.d/init.d/. Такие скрипты обычно писались на Bash и позволяли администратору управлять состоянием сервисов и демонов. В CentOS 7 скрипты инициализации были заменены сервисными юнитами.



По способу использования сервисные юниты .service напоминают скрипты инициализации. Для просмотра, старта, остановки, перезагрузки, включения или выключения системных сервисов используется команда systemctl. Команды service и chkconfig по-прежнему включены в систему, но только по соображениям совместимости.





При использовании systemctl указывать расширение файла не обязательно.



Ниже представлены основные команды systemctl:

  • systemctl start name.service – запуск сервиса.
  • systemctl stop name.service — остановка сервиса
  • systemctl restart name.service — перезапуск сервиса
  • systemctl try-restart name.service — перезапуск сервиса только, если он запущен
  • systemctl reload name.service — перезагрузка конфигурации сервиса
  • systemctl status name.service — проверка, запущен ли сервис с детальным выводом состояния сервиса
  • systemctl is-active name.service — проверка, запущен ли сервис с простым ответом: active или inactive
  • systemctl list-units --type service --all – отображение статуса всех сервисов
  • systemctl enable name.service – активирует сервис (позволяет стартовать во время запуска системы)
  • systemctl disable name.service – деактивирует сервис
  • systemctl reenable name.service – деактивирует сервис и сразу активирует его
  • systemctl is–enabled name.service – проверяет, активирован ли сервис
  • systemctl list-unit-files --type service – отображает все сервисы и проверяет, какие из них активированы
  • systemctl mask name.service – заменяет файл сервиса симлинком на /dev/null, делая юнит недоступным для systemd
  • systemctl unmask name.service – возвращает файл сервиса, делая юнит доступным для systemd


Работаем с целями (targets) Systemd

Предыдущие версии CentOS с SysV init или Upstart включали предопределенный набор уровней запуска (runlevels), которые представляли специфичные режимы для операций, пронумерованные от 0 до 6. В CentOS 7 концепция уровней запуска была заменена целями systemd.



Файлы целей systemd .target предназначены для группировки вместе других юнитов systemd через цепочку зависимостей. Например юнит graphical.target, использующийся для старта графической сессии, запускает системные сервисы GNOME Display Manager (gdm.service) и Accounts Service (accounts–daemon.service) и активирует multi–user.target. В свою очередь multi–user.target запускает другие системные сервисы, такие как Network Manager (NetworkManager.service) или D-Bus (dbus.service) и активирует другие целевые юниты basic.target.



В CentOS 7 присутствуют предопределенные цели, похожие на стандартный набор уровней запуска. По соображениям совместимости они также имеют алиасы на эти цели, которые напрямую отображаются в уровнях запуска SysV.



  • poweroff.target (runlevel0.target) – завершение работы и отключение системы
  • rescue.target (runlevel1.target) – настройка оболочки восстановления
  • multi–user.target (runlevel2.target, runlevel3.target, runlevel4.target) – настройка неграфической многопользовательской системы
  • graphical.target (runlevel5.target) – настройка графической многопользовательской системы
  • reboot.target (runlevel6.target) – выключение и перезагрузка системы


Команды runlevel и telinit по-прежнему доступны, но оставлены в системе по соображениям совместимости. Рекомендуется использовать systemctl для изменения или настройки системных целей.



Для определения, какой целевой юнит используется по умолчанию, полезна следующая команда: systemctl get–default.



Для просмотра всех загруженных целевых юнитов воспользуйтесь командой systemctl list-units --type target, а для просмотра вообще всех целевых юнитов командой: systemctl list-units --type target --all.



Для изменения цели по умолчанию поможет команда systemctl set-default name.target.



Для изменения текущей цели: systemctl isolate name.target. Команда запустит целевой юнит и все его зависимости и немедленно остановит все остальные.



Выключение и перезагрузка системы

В CentOS 7 systemctl заменяет значительное количество команд управления питанием. Прежние команды сохранены для совместимости, но рекомандуется использовать systemctl:

systemctl halt – останавливает систему

systemctl poweroff – выключает систему

systemctl reboot – перезагружает систему



Управление systemd на удаленной машине

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

systemctl --host user_name@host_name command, где user_name – имя пользователя, host_name – имя хоста, которым осуществляется удаленное управление, а command – выполняемая команда systemd.



Типичный systemd .service

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



[Unit]
Description=Daemon to detect crashing apps
After=syslog.target

[Service]
ExecStart=/usr/sbin/abrtd
Type=forking

[Install]
WantedBy=multi-user.target


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



В следующей секции [Service] непосредственно содержится информация о нашем сервисе. Используемый параметр ExecStart указывает на исполняемый файл нашего сервиса. В Type мы указываем, как сервис уведомляет systemd об окончании запуска.



Финальная секция [Install] содержит информацию о цели, в которой сервис должен стартовать. В данном случае мы говорим, что сервис должен быть запущен, когда будет активирована цель multi–user.target.



Это минимальный работающий файл сервиса systemd. Написав свой, для тестирования скопируйте его в /etc/systemd/system/имя_сервиса.service. Выполните команды systemctl daemon-reload. Systemd узнает о сервисе и вы сможете его запустить.



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

Отличное руководство по systemd от RedHat, положенное в основу этой статьи.

Документация по написанию своего сервис-юнита systemd.

«Systemd для администраторов» от разработчика systemd на русском языке.

#############################################################################


пример юнита пользовательского скрипта

nano /etc/systemd/system/start-unicor1.service



после каждого редактирования юнита необходимо делать systemctl daemon-reload
проверка через запуск
systemctl start start-unicor1.servic

остановка
systemctl start start-unicor1.servic

сам скрипт для юнита



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



вариант запуска по cron
@reboot /home/user1/start_unicor.sh




поскольку ruby установлен локально в домашнюю папку, то требуется инициализация source /home/user1/.profile и тд.

Как передать переменные окружения службе, запущенной systemd?
[Service]
Environment=KEY=VALUE
или так
EnvironmentFile=/path/to/env

Для нескольких значений env
Environment=KEY=VALUE
Environment=KEY2=VALUE2 KEY3=VALUE3


Поднимаем на одном сервере несколько Ruby on Rails проектов под разными версиями ruby (Nginx + Unicorn)
установка и защита redis в centos 7
Systemd за пять минут
Пишем systemd Unit файл





https://infoboxcloud.ru/community/blog/infoboxcloud/201.html



systemd
/usr/lib/systemd/system/: юниты, предоставляемые пакетами при их установке
/etc/systemd/system/: юниты, устанавливаемые системным администратором

Просмотреть список всех активных юнитов
$ systemctl list-units

Покажет любой юнит, который система загрузила или попыталась загрузить, независимо от текущего состояния в системе
$ systemctl list-units --all

неактивные юниты:
$ systemctl list-units --all --state=inactive

Посмотреть только активные юниты служб:
$ systemctl list-units --type=service

Вывод списка всех файлов юнитов
$ systemctl list-unit-files

Посмотреть только юниты, добавленные в автозагрузку:
$ systemctl list-unit-files | grep enabled

Увидеть дерево зависимостей юнита:
$ systemctl list-dependencies юнит
Чтобы показать обратные зависимости (юниты, зависящие от указанного юнита), вы можете добавить в команду флаг --reverse.

Проверка свойств юнита:
$ systemctl show юнит

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

Незамедлительно остановить юнит:
# systemctl stop юнит

Перезапустить юнит:
# systemctl restart юнит

Попросить юнита перезагрузить его настройки:
# systemctl reload юнит

Показать статус юнита, а также запущен он или нет:
$ systemctl status юнит

Проверить, включен ли юнит в автозапуск при загрузке системы:
$ systemctl is-enabled юнит

Проверить, активен ли данный юнит:
$ systemctl is-active юнит

Включить юнит в автозапуск при загрузке системы:
# systemctl enable юнит

Убрать юнит из автозапуска при загрузке системы:
# systemctl disable юнит

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

Снять маску юнита:
# systemctl unmask юнит

Показать страницу справочного руководства, связанного с юнитом (необходима поддержка этой функции в указанном файле юнита):
$ systemctl help юнит

Перезагрузить systemd для поиска новых или измененных юнитов:
# systemctl daemon-reload

список запущенных юнитов
$ systemctl list-unit-files | grep enabled

службы systemd, которые не смогли запуститься:
$ systemctl --failed

какие именно системные компоненты заставляют systemd ждать так долго
$ systemd-analyze blame




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

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

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

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

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

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

https://wiki.archlinux.org/index.php/Systemd_(Русский)
Как использовать Systemctl для управления службами Systemd и юнитами

список команд systemd
systemd-analyze                - выводит информацию о времени загрузки системы и ее производительности
systemctl                      - основная команда для управления службами и юнитами в systemd. Используется для запуска, остановки, перезапуска и проверки статуса служб
systemd-cgls                   - выводит древовидную структуру контрольных групп (cgroups)
systemd-cgtop                  - выводит список процессов, запущенных в контрольных группах
systemd-analyze blame          - выводит список юнитов и время, затраченное на их запуск
systemd-analyze critical-chain - выводит диаграмму зависимостей юнитов и время, затраченное на запуск каждого из них
systemd-delta                  - показывает изменения в конфигурационных файлах, сделанные пользователем или системой
systemd-nspawn                 - запускает новый процесс в изолированном окружении
systemd-run                    - запускает произвольную команду в новом юните systemd
systemd-escape                 - кодирует или декодирует строку для использования в юнит-файлах systemd
journalctl                     - просмотр журнала системных сообщений
localectl                      - управление настройками локализации и клавиатуры
timedatectl                    - управление настройками времени и даты

journalctl
Доступ к журналу
gpasswd -a $USER wheel

Фильтрация сообщений по уровню ошибки

Вывод лога в текстовый файл
journalctl -b > /home/user/debug.log

Показывать записи журнала с момента запуска системы с расшифровкой ошибок:
journalctl -xb


journalctl -b # последняя загрузка
journalctl -b -1 # предыдущая загрузка

journalctl -b 0
journalctl -p err -b
journalctl -p err -b -1 -u NetworkManager

0 — EMERG (система неработоспособна);
1 — ALERT (требуется немедленное вмешательство);
2 — CRIT (критическое состояние);
3 — ERR (ошибка);
4 — WARNING (предупреждение);
5 — NOTICE (всё нормально, но следует обратить внимание);
6 — INFO (информационное сообщение);
7 —DEBUG (отложенная печать)

Просмотр сообщений ядра
journalctl -k
journalctl -k -b -2
journalctl --dmesg

Фильтрация по приложениям и службам
journalctl -u httpd.service -u mysql.service
journalctl -u nginx.service -u php-fpm.service —since today

Фильтрация по процессам, пользователям и группам

Просмотреть список всех доступных фильтров
man systemd.journal-fields

journalctl -F _PID # процессы
journalctl -F _UID # пользователи
journalctl -F _GID # группы

просмотреть логи всех процессов, запущенных от имени этого пользователя:
id -u www-data
journalctl _UID=33

Фильтрация по пути
journalctl /usr/bin/docker

фильтрация по дате и времени
journalctl --since "2017-05-05 00:01" --until "2017-05-06 01:40"


cat — только сообщения из логов без служебных полей;
export — бинарный формат, подходит для экспорта или резервного копирования логов;
short — формат вывода syslog;
short-iso — формат вывода syslog с метками времени в формате ISO 8601;
short-monotonic — формат вывода syslog c метками монотонного времени (monotonic timestamp);
short-precise — формат вывода syslog с метками точного времени (время событий указывается с точностью до микросекунд);
verbose — максимально подробный формат представления данных (включает даже те поля, которые в других форматах не отображаются).


Просмотр логов в режиме реального времени
journalctl -f

Просмотр информации о недавних событиях
journalctl -n
journalctl -n 20

Запись в журнал
systemd-cat echo "Текст сообщения"
journalctl -f
апр 18 01:14:13 arch1 echo[4822]: Текст сообщения

Поиск информации в журнале
journalctl SYSLOG_IDENTIFIER=Test
выводит все сообщения имеющие идентификатор сообщения Test.

Запись логов в стандартный вывод
journalctl --no-pager > log.txt

Выбор формата вывода
journalctl -u nginx.service -o json


Анализ этапа загрузки
Выявляем самые медленные процессы (от пользователя):

systemd-analyze blame
Выводим график загрузки процессов в векторный рисунок:

systemd-analyze plot > file.svg

Управление логгированием

Текущие разрешенные лимиты для журналов на диске и в памяти
systemctl status systemd-journald
journalctl -t systemd-journald

Все загрузки системы
journalctl --list-boots

Определение текущего объёма логов
journalctl --disk-usage

Настройка ротации логов в конфигурационном файле

/etc/systemd/journald.conf
/var/log/journal/

SystemMaxUse= максимальный объём, который логи могут занимать на диске;
SystemKeepFree= объём свободного места, которое должно оставаться на диске после сохранения логов;
SystemMaxFileSize= объём файла лога, по достижении которого он должен быть удален с диска;
RuntimeMaxUse= максимальный объём, который логи могут занимать в файловой системе /run;
RuntimeKeepFree= объём свободного места, которое должно оставаться в файловой системе /run после сохранения логов;
RuntimeMaxFileSize= объём файла лога, по достижении которого он должен быть удален из файловой системы /run.


systemctl restart systemd-journald # применить конфигурацию
journalctl --vacuum-size=100M # автоматически удалять все логи при превышении объёма
journalctl --vacuum-time=1months # Удалить все логии старше последнего месяца
systemctl status systemd-journald
journalctl -t systemd-journald

Централизованное хранение логов

С помощью команды systemd-journal-remote можно принимать логи с удалённых хостов
на каждом их этих хостов должен быть запущен демон systemd-journal-gatewayd
systemd-journal-remote −−url https://some.host:19531/

Команда systemd-journal-upload используется для загрузки логов с локальной машины в удалённое хранилище:
systemd-journal-upload --url https://some.host:19531/
journalctl -o export | systemd-journal-remote -o /tmp/dir -


coredumpctl
https://www.altlinux.org/Features/Core
5 инструментов из состава systemd, которые следует начать использовать прямо сейчас

Очистка списка coredumpctl
Сначала удалить журнал, удалив записи старше одного дня:
journalctl --vacuum-time=1d
Поскольку в списке «coredumpctl» перечислены файлы дампа, записанные журналом, вы можете вручную удалить файлы дампа из /var/lib/systemd/coredump, которых нет в списке.
coredumpctl list

На эту статью меня натолкнула установка клиента qbittorrent, с доступом к нему через webgui. После интсталяции обнаружил что он почему-то не хочет стартовать в виде демона и поэтому встал вопрос о запуске.

Read more... )
http://liberatum.ru/blog/26717

Profile

uzverss: (Default)
uzverss

December 2024

S M T W T F S
12345 67
891011121314
15161718192021
22232425262728
293031    

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jan. 22nd, 2026 12:49 am
Powered by Dreamwidth Studios