Шпаргалка з управління сервісами CentOS 7 з systemd

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

У цій статті ми розглянемо процес управління сервісами в systemd для користувача CentOS 7. Ці знання будуть корисні і в інших дистрибутивах, адже systemd вже давно використовується в Fedora і планується в Ubuntu 14.10 та Debian 8. Добре це чи ні — залишимо за кадром.

CentOS 7 Systemd Іnfobox

У процесі читання статті ви можете спробувати systemd на класичних VPS і хмарних VPS від Іnfobox. Ми прагнемо своєчасно додавати підтримку сучасних ОС, щоб ви могли використовувати останні технології для більш ефективної роботи. Сама ідея написання статті народилася після чергового запитання користувачів про використання сервісів в 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 чи Вискочка. Сценарії ініціалізації розташовувалися в директорії /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 чи Вискочка включали стандартний набір рівнів запуску (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 --target type, а для перегляду взагалі всіх цільових юнітів командою: 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 російською мовою.

Висновок

У цій статті ми навчилися управляти сервісами CentOS 7. Звичайно, це далеко не єдина функція systemd і інші її сторони будуть розглянуті в майбутньому. Сама ОС практично з часу релізу доступна на класичних VPS і хмарних VPS від Іnfobox. Спробуйте systemd прямо зараз. Ці знання будуть корисні в зв'язку з переходом багатьох дистрибутивів на systemd.

Якщо ви виявили помилку у статті, автор її з задоволенням виправить. Будь ласка напишіть в ЛС або на пошту.
У разі, якщо ви не можете залишати коментарі на Хабре, можна написати їх у блозі Співтовариства InfoboxCloud або в нашій групі в Facebook.

Успішного використання CentOS 7!

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.