Модуль 0.4: Сервіси та логи без таємниць

Щоденне використання | Складність: [QUICK] | Час: 40 хв

Передумови

Перед початком цього модуля:

Обов’язково: Модуль 0.3: Путівник по процесах і ресурсах
Бажано: Мати систему Linux із доступом sudo

Що ви зможете робити після цього модуля

Після завершення цього модуля ви зможете:

Керувати сервісами за допомогою systemctl (start, stop, enable, status) та читати їхню конфігурацію
Запитувати логи через journalctl з фільтрами за часом, юнітами та пріоритетом
Діагностувати сервіс, що не запускається, читаючи записи журналу та залежності unit-файлу
Пояснити зв’язок між systemd, journald та syslog

Чому цей модуль важливий

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

Ці фонові програми називаються сервісами (або демонами), і вони є основою кожного сервера Linux. Ваш вебсервер, база даних, середовище виконання контейнерів, SSH-сервер — усе це сервіси, якими керує система під назвою systemd.

Розуміння сервісів та логів допоможе вам:

Підтримувати роботу — Запускати, зупиняти й перезапускати сервіси без перезавантаження всієї машини.
Виживати на чергуванні — Коли щось ламається о 2-й ночі, логи розкажуть вам, що саме сталося.
Налагодити Kubernetes — kubelet, containerd та etcd — це сервіси systemd «під капотом».
Впевнено деплоїти — Знати, як гарантувати, що ваш застосунок запуститься при старті й не вимкнеться сам по собі.

Цей модуль заповнює прогалину між «я вмію запустити команду» та «я вмію керувати продакшн-сервісом».

Чи знали ви?

Слово «демон» (daemon) походить із грецької міфології — Демон Максвелла був уявним помічником, що працював у фоні. Unix перейняв цей термін у 1960-х для фонових процесів. Маскот BSD — це буквально демон із тризубом.
systemd керує набагато більшим, ніж просто сервісами — Він відповідає за налаштування мережі, резолвінг DNS, синхронізацію часу, логін-сесії й навіть очищення тимчасових файлів. На типовому сервері systemd керує понад 100 різними компонентами.
journald може зберігати логи після перезавантаження — За замовчуванням у багатьох системах логи втрачаються при ребуті. Але якщо ввімкнути постійне зберігання, ви зможете перевірити, що сталося за мить до останнього падіння сервера. Це критично для пошуку причин проблем у вузлах Kubernetes.
Один неправильно налаштований сервіс може заблокувати завантаження системи — Якщо сервіс позначений як обов’язковий (required) і він не запускається, ви можете опинитися в консолі відновлення. Тому розуміння enable/disable та залежностей сервісів справді важливе.

Від процесів до сервісів

У Модулі 0.3 ви запускали команди типу sleep 300 & для фонової роботи. Це підходить для коротких завдань, але має проблеми для справжніх програм:

Запуск команди	Запуск сервісу
Вмирає при закритті термінала	Виживає після закриття термінала та ребутів
Немає авто-перезапуску при збої	Перезапускається сам, якщо впав
Логи йдуть у термінал (і губляться)	Логи збираються і зберігаються journald
Керуєте вручну	systemd керує за вас
Немає черговості залежностей	Запускається тільки тоді, коли база даних готова

Уявіть це так: запуск python app.py & — це як попросити друга потримати двері. Запуск сервісу systemd — це як встановити автоматичні двері: вони працюють незалежно від того, чи стоїть хтось поруч.

Що таке демон (Daemon)?

Демон — це просто процес, що працює в фоні без підключеного до нього термінала. За домовленістю назви демонів часто закінчуються на літеру «d»:

sshd — демон SSH (обробляє віддалені підключення).
containerd — демон контейнерів (запускає контейнери для Kubernetes).
kubelet — технічно назва не на «d», але це теж демон.

Що таке systemd?

systemd — це система ініціалізації та менеджер сервісів у майже всіх сучасних дистрибутивах Linux. Це найперший процес, що запускається (PID 1), і він відповідає за:

Запуск сервісів у правильному порядку при старті системи.
Нагляд за сервісами та їх перезапуск у разі збоїв.
Збір логів з усіх сервісів в одне місце (journald).
Керування залежностями — гарантування, що база даних запуститься раніше за додаток, який її потребує.

Think of systemd as the shift manager at a restaurant. It does not cook or serve food, but it makes sure the cooks and servers show up on time, in the right order, and gets replacements if someone calls in sick.

┌──────────────────────────────────────────────────────────┐
│                    systemd (PID 1)                        │
│                  "Менеджер зміни"                         │
├──────────────────────────────────────────────────────────┤
│                                                          │
│   ┌──────────┐  ┌──────────┐  ┌──────────┐              │
│   │  sshd    │  │  nginx   │  │containerd│              │
│   │(віддал.  │  │  (веб-   │  │(рантайм  │              │
│   │ доступ)  │  │  сервер) │  │контейнер)│              │
│   └──────────┘  └──────────┘  └──────────┘              │
│                                                          │
│   ┌──────────┐  ┌──────────┐  ┌──────────┐              │
│   │ kubelet  │  │ chronyd  │  │  rsyslog │              │
│   │ (k8s     │  │  (час)   │  │ (збір    │              │
│   │ агент)   │  │          │  │  логів)  │              │
│   └──────────┘  └──────────┘  └──────────┘              │
│                                                          │
│   Хтось упав? → systemd перезапускає                     │
│   При включенні → запускає в правильному порядку         │
└──────────────────────────────────────────────────────────┘

Керування сервісами через systemctl

systemctl — це команда, яку ви використовуєте для спілкування з systemd. Це ваш головний інструмент.

Перевірка статусу

Найчастіше ви будете перевіряти, чи працює сервіс:

# Перевірити статус nginx
systemctl status nginx

Вивід покаже:

Чи завантажений файл сервісу.
Active: чи він запущений (running) чи зупинений (inactive).
Main PID: номер головного процесу.
Logs: останні кілька рядків виводу програми.

Кольорова крапка зліва підкаже стан:

Зелена ● — працює.
Біла ○ — зупинено.
Червона ● — помилка.

Старт, Стоп та Рестарт

# Запустити зупинений сервіс
sudo systemctl start nginx

# Зупинити сервіс
sudo systemctl stop nginx

# Перезапустити (stop + start)
sudo systemctl restart nginx

# Перезавантажити конфіг (reload) — без обриву з'єднань
# Не всі сервіси це підтримують
sudo systemctl reload nginx

Коли робити restart, а коли reload?

Restart повністю вбиває процес і запускає новий. З’єднання з сервером обриваються. Використовуйте, якщо змінили щось суттєве.
Reload каже процесу перечитати свої налаштування «на льоту». З’єднання залишаються живими. Використовуйте при зміні конфіг-файлів.

Порада: Не впевнені, чи підтримує сервіс reload? Використовуйте systemctl reload-or-restart nginx.

Автовключення при старті (Enable/Disable)

Запуск сервісу (start) робить його робочим зараз. Включення (enable) робить так, щоб він запускався автоматично при старті комп’ютера:

# Ввімкнути автозапуск nginx
sudo systemctl enable nginx

# Вимкнути автозапуск
sudo systemctl disable nginx

# Ввімкнути І запустити одночасно
sudo systemctl enable --now nginx

# Перевірити, чи ввімкнено автозапуск
systemctl is-enabled nginx

Перегляд логів через journalctl

Усі сервіси systemd відправляють свої повідомлення в journald. Ви читаєте їх через journalctl.

Основні команди

# Подивитися ВСІ логи (обережно, їх дуже багато)
journalctl

# Перейти в самий кінець (найсвіжіші записи)
journalctl -e

# Стежити за логами наживо (як tail -f)
journalctl -f

Фільтрація (найважливіше)

Найчастіше вам потрібні логи конкретного сервісу. Прапор -u означає “Unit”:

# Тільки логи nginx
journalctl -u nginx

# Логи nginx в реальному часі
journalctl -u nginx -f

# Логи тільки з сьогоднішнього дня
journalctl -u nginx --since today

# Тільки помилки
journalctl -u nginx -p err

Пріоритет	Ключове слово	Що це означає
3	err	Помилки
4	warning	Попередження
6	info	Інформаційні повідомлення

Чому systemd кращий за nohup?

Ви можете запитати: «Чому б просто не запускати програму як nohup python app.py &?». В продакшні так не роблять, і ось чому:

# Шлях nohup — крихкий
nohup python /opt/app.py > /var/log/app.log 2>&1 &
# Що, як він впаде о 3-й ночі?
# Нічого. Він залишиться мертвим. Ви плачете.

# Шлях systemd — надійний
sudo systemctl start myapp
# Що, як він впаде о 3-й ночі?
# systemd миттєво його перезапустить.
# Ви спокійно спите.

Типовий шлях вирішення проблем (Troubleshooting)

Коли сервіс не працює, дотримуйтесь цього алгоритму:

Перевірте статус: systemctl status назва (Чи він взагалі живий?).
Подивіться логи: journalctl -u назва -n 50 --no-pager (Що він “сказав” перед смертю?).
Спробуйте запустити: sudo systemctl start назва.
Якщо впав відразу — знову в логи, там буде причина (немає доступу до файлу, зайнятий порт тощо).
Виправте конфіг і зробіть sudo systemctl restart назва.

Типові помилки

Помилка	Наслідки	Рішення
Забули `sudo`	Команда не виконається (Permission denied)	Команди зміни стану (start/stop) потребують root
Плутанина між `enable` та `start`	«Я ж увімкнув, а він не працює!»	`enable` — це про майбутній старт, `start` — про зараз
Не дивитися в логи після збою	Гадання замість знання причини	Завжди дивіться `journalctl -u`
Використання `kill` замість `systemctl stop`	systemd подумає, що це збій, і перезапустить сервіс	Зупиняйте сервіси правильно через systemctl

Тест

Яка різниця між systemctl start та systemctl enable?

Відповідь
`start` запускає сервіс негайно в поточній сесії. `enable` налаштовує систему так, щоб сервіс запускався автоматично кожного разу при включенні (boot) комп'ютера.
Як подивитися останні 20 рядків логів сервісу sshd і стежити за новими?

Відповідь
`journalctl -u sshd -n 20 -f`. Прапор `-n 20` обмежує кількість рядків, а `-f` вмикає режим стеження.
Сервіс “myapp” постійно перезапускається. Де шукати причину?

Відповідь
У логах цього сервісу: `journalctl -u myapp`. Зазвичай там буде повідомлення про помилку (Error), яке пояснює, чому програма аварійно завершується.
Навіщо використовувати systemctl reload замість restart?

Відповідь
`reload` дозволяє застосувати нові налаштування без повної зупинки програми. Це зберігає активні з'єднання користувачів, тоді як `restart` обриває все і створює новий процес з нуля.

Практична вправа

Завдання: Встановити вебсервер nginx, покерувати його життям та дослідити логи.

Встановіть nginx:

sudo apt update && sudo apt install -y nginx

Перевірте, чи він працює:
Terminal window
```
systemctl status nginx
```
Зупиніть його і переконайтеся, що він “dead”:
Terminal window
```
sudo systemctl stop nginx
systemctl status nginx
```
Знову запустіть:
Terminal window
```
sudo systemctl start nginx
```
Подивіться на записи про запуск у журналі:
Terminal window
```
journalctl -u nginx -n 20
```
Перевірте, чи ввімкнено автозапуск при старті системи:
Terminal window
```
systemctl is-enabled nginx
```

Критерії успіху: Ви вмієте перевіряти стан сервісу, керувати його роботою та читати його логи.

Підсумок

Сервіси — це фундамент сервера Linux:

Ними керує systemd (PID 1).
Ви керуєте ними через systemctl.
Логи збираються в journalctl.

Головні уроки:

start — зараз, enable — назавжди.
Логи — ваше перше джерело правди при проблемах.
У продакшні завжди використовуйте сервіси замість ручного запуску команд.

Далі: Модуль 0.5: Щоденні мережеві інструменти — навчіться перевіряти зв’язок, порти та DNS.