Модуль 26

Systemd та керування сервісами

Ось урок, створений спеціально для тебе у стилі David Malan. Приготуйся, зараз ми перетворимо магію Linux на зрозумілу логіку.

🎓 Тема: Systemd — Серцебиття твого Linux-сервера

Привіт, друзі! Радий бачити вас знову.

Сьогодні ми поговоримо про дещо фундаментальне. Дещо, що відрізняє аматора, який запускає скрипти "на колінці", від професіонала, який будує надійні системи.

1. 🔥 Вступ: Проблема «Зниклого бота»

Уявіть ситуацію. Ви написали геніального Telegram-бота на Python. Він ідеальний. Ви заходите на сервер через SSH, пишете: python3 my_super_bot.py ...і він працює! Ви задоволені, закриваєте термінал, йдете пити каву.

Повертаєтесь — а бот мовчить. Чому?

Тому що коли ви закрили термінал, ви вбили сесію, і разом з нею — вашого бота.

Добре, скажете ви, я запущу його у фоні! А що, якщо сервер перезавантажиться вночі через оновлення? Ваш бот сам не прокинеться. А що, якщо в коді станеться помилка і він "впаде"? Він лежатиме, доки ви не прийдете і не "штовхнете" його знову.

Питання до вас: Чи хотіли б ви бути нянькою для своїх програм 24/7? Прокидатися о 3-й ночі, щоб просто перезапустити скрипт?

Звісно, ні. Нам потрібен хтось надійний. Хтось, хто прокидається разом із комп’ютером, запускає все необхідне, слідкує за порядком, і якщо хтось "впав" — піднімає його.

Цей "хтось" — це Systemd.

Аналогія: Уявіть великий готель. * Програми — це персонал (кухарі, прибиральники). * Kernel (Ядро) — це власник будівлі (дає ресурси). * Systemd — це Головний Управитель. Він відкриває готель зранку, перевіряє, чи є вода (мережа), перш ніж пустити кухарів (веб-сервер), і якщо швейцар заснув — будить його відром води (перезапуск процесу).

2. 🧠 Теоретична база (Як це працює під капотом)

Давайте заглянемо всередину.

Systemd — це система ініціалізації. Коли Linux завантажується, першим запускається Ядро, а одразу за ним — процес із PID 1 (Process ID #1). Це і є Systemd. Всі інші процеси — це його діти, онуки або правнуки.

Три кити Systemd, які треба знати:

  1. Unit (Юніт/Одиниця): Це будь-який ресурс, яким керує systemd. Це може бути сервіс, точка монтування диска або таймер.
    • Інтуїтивно: Це "інструкція" для управителя.
  2. Service (.service): Найпопулярніший тип юніта. Це опис вашої програми: "Де лежить файл?", "Як його запустити?", "Що робити, якщо він вмер?".
  3. Target (Ціль): Це група юнітів. Наприклад, multi-user.target означає "режим, коли система готова приймати користувачів". Це як чекпоінт у грі.

Як думає Systemd?

Він не виконує все підряд списком (як старі системи). Він будує дерево залежностей. Він каже: "Ага, щоб запустити Nginx, мені потрібна Мережа. Значить, я спочатку чекаю Мережу, а потім стартую Nginx". І робить це максимально паралельно, щоб сервер завантажився за секунди.

3. 🧪 Приклади (Від простого до реального)

Приклад 1: Спостереження (Hello World у світі адміністрування)

Кожен Linux-сервер має службу SSH (завдяки якій ми підключаємось). Давайте запитаємо у Systemd, як справи у SSH.

Введіть у терміналі:

systemctl status ssh
# або sshd, залежно від дистрибутиву

Що ви очікуєте побачити? Просто "працює"?

Насправді ви побачите дещо більше: * 🟢 Active: active (running) — це найголовніше. Зелене світло. * Loaded: /lib/systemd/system/ssh.service — звідки він взяв інструкцію. * Log snippet: останні кілька рядків логів (хто підключався).

Приклад 2: Створюємо безсмертного бота (Реальний кейс)

Припустимо, у нас є скрипт /opt/mybot/main.py. Зробимо його сервісом.

Ми створюємо файл інструкції. У Systemd всі користувацькі інструкції живуть у /etc/systemd/system/.

Створимо файл mybot.service:

[Unit]
Description=Мій геніальний бот
After=network.target
# Ми кажемо: "Не запускай мене, поки немає інтернету!"

[Service]
Type=simple
User=root
WorkingDirectory=/opt/mybot
ExecStart=/usr/bin/python3 /opt/mybot/main.py
Restart=always
# Оце — магія безсмертя. Якщо впав — вставай!

[Install]
WantedBy=multi-user.target
# Це означає: "Запускай мене автоматично, коли сервер завантажується у звичайний режим"

Пояснення логіки: Ми не просто сказали "запусти". Ми сказали коли запустити (After), як запустити (ExecStart) і що робити при біді (Restart).

4. 🛠 Практична частина

Час забруднити руки. Не бійтеся, ви нічого не зламаєте (якщо не будете видаляти системні файли).

Завдання 1: "Fake Service"

  1. Створіть простий скрипт, який імітує роботу. bash # Створіть файл /root/fake_process.sh echo '#!/bin/bash while true; do echo "Я працюю... $(date)" >> /tmp/log_fake.txt sleep 5 done' > /root/fake_process.sh chmod +x /root/fake_process.sh
  2. Переконайтесь, що він працює, запустивши ./fake_process.sh, а потім зупиніть (Ctrl+C).

Завдання 2: "Реєстрація управителя"

Створіть файл /etc/systemd/system/fake.service з таким вмістом:

[Unit]
Description=Фейковий процес для навчання

[Service]
ExecStart=/root/fake_process.sh
Restart=always

[Install]
WantedBy=multi-user.target

Завдання 3: "Запуск"

Виконайте команди:

sudo systemctl daemon-reload  # Скажіть Systemd перечитати файли!
sudo systemctl start fake     # Запустіть сервіс
sudo systemctl status fake    # Перевірте статус

Питання: Який PID (Process ID) у вашого процесу? (Це видно у status).

Завдання 4: "Тест на безсмертя" 💀

Ось найцікавіше. 1. Запам'ятайте PID із попереднього кроку (наприклад, 12345). 2. Жорстоко вбийте процес: sudo kill -9 12345. 3. Одразу перевірте статус знову: sudo systemctl status fake.

Що сталося? PID змінився! Systemd побачив смерть процесу і миттєво запустив новий.

Завдання 5: "Автозавантаження"

Зараз, якщо ви перезавантажите сервер, сервіс не встане сам. Чому? Бо ми його тільки запустили (start), але не додали в автозавантаження. Зробіть це:

sudo systemctl enable fake

Тепер він переживе навіть ядерну зиму (ну, або перезавантаження сервера).

5. 💡 Мислення як у розробника

Як відрізнити новачка від профі в роботі з Systemd?

  1. Новачок редагує файл .service і дивується, чому нічого не змінилося.

    • Профі знає: Systemd кешує файли. Після кожної зміни у файлі конфігурації треба робити: sudo systemctl daemon-reload. Запам'ятайте це як "Ctrl+S" для Systemd.

  2. Новачок пише шлях до файлу просто як python script.py.

    • Профі завжди пише абсолютні шляхи: /usr/bin/python3 /home/user/project/script.py. Systemd не знає вашої змінної PATH. Він сліпий кошеня без повних адрес.

  3. Порада: Якщо сервіс не стартує, systemctl status показує обрізану інформацію. Використовуйте journalctl -u fake.service -e (або -f для перегляду в реальному часі), щоб прочитати повні логи і зрозуміти причину падіння.

6. 🧩 Підсумок

Отже, що ми сьогодні зробили? 1. Зрозуміли, що Systemd — це управитель готелю Linux. 2. Навчилися писати Unit-файли, щоб перетворювати скрипти на повноцінні сервіси. 3. Налаштували автоматичний перезапуск (Restart) та автозавантаження (Enable).

Тепер ваші програми працюють професійно. Вони не бояться перезавантажень і падінь. Ви можете спати спокійно.

Тизер наступного уроку: Ваш сервіс працює, але він пише логи просто в текстовий файл або в порожнечу. Як знайти помилку, яка сталася 3 дні тому? Наступного разу ми зануримось у Journald та аналіз логів. Там буде багато детективної роботи.

А поки що — практикуйтесь. Спробуйте "задемонізувати" щось своє! Успіхів! 🚀

← До списку уроків Наступний урок →