Система изнутри: ресурсы, ядро, процессы / Ступень 10 из 12 · шаг 7 из 8

Служба держит загрузку

~25 мин

Не запущена Запускается обычно ~20 с

Ситуация

На складском сервере работают две службы: приём заказов lab-orders (http://127.0.0.1:8090) и хранилище остатков lab-stock. Приём заказов при запуске берёт остатки у хранилища — без них заказы не принимает.

После каждой перезагрузки сервер грузится на полминуты дольше, а lab-orders оказывается упавшей — дежурный потом поднимает службы руками. Коллега уверяет, что зависимости служб настроил; юниты лежат в /etc/systemd/system/.

Машина сейчас — как после такой загрузки: lab-orders только что пыталась запуститься.

Задача

lab-orders сама запускает хранилище lab-stock и стартует после него: зависимости — в её юните (Wants= и After=), встречного порядка нет.
systemd-analyze verify lab-orders.service lab-stock.service не печатает предупреждений.
lab-orders работает, включена при загрузке и отвечает: curl http://127.0.0.1:8090/health.
После перезагрузки (sudo reboot) lab-orders поднимается сама с первой попытки и держит загрузку не дольше 10 секунд.

Ограничения

Код приложений — /usr/local/bin/order-desk и /usr/local/bin/stock-store — не меняй.
Перезагружать машину можно сколько угодно: терминал покажет загрузку и снова войдёт под student. «Проверить» смотрит загрузку, которая прошла после подготовки машины, поэтому перезагрузи её после правки.

Интернета на машине нет, всё нужное установлено. Как идёт запуск службы, видно в systemctl status lab-orders и journalctl -u lab-orders; что держит загрузку — в systemd-analyze blame и systemd-analyze critical-chain.

Цели лабы

0 из 4

lab-orders сама запускает хранилище lab-stock и стартует после него (Wants= и After=), встречного порядка нет — ещё не проверялась
systemd-analyze verify lab-orders.service lab-stock.service — без предупреждений — ещё не проверялась
lab-orders работает, включена при загрузке и отвечает на http://127.0.0.1:8090/health; код приложений прежний — ещё не проверялась
После перезагрузки (sudo reboot) lab-orders поднялась сама с первой попытки и держала загрузку не дольше 10 с — ещё не проверялась

Подсказки

открыто 0 из 3 · открываются по одной

Подсказка 1

Показать решение после 3 неудачных проверок

Для запуска машины нужен вход

Машина запускается на твой аккаунт, там же хранится прогресс. Читать можно без входа.

После входа вернёшься на эту лабу.

Службы и systemd · подобрано по лабе

systemd

Шпаргалка

$_ — вставить в терминал

systemctl status nginx состояние
systemctl start nginx запустить сейчас
systemctl stop nginx остановить сейчас
systemctl enable nginx включить автозапуск
systemctl reload nginx перечитать конфиг без обрыва
systemctl daemon-reload после правки юнит-файлов
journalctl -u nginx -f логи службы в реальном времени
systemd-analyze blame тайминги загрузки

Юниты ищутся в (по возрастанию приоритета):

/lib/systemd/system/ — пакетные (не редактировать);
/etc/systemd/system/ — локальные переопределения (редактировать здесь).

Структура .service:

ini

[Unit]
Description=My App
After=network-online.target

[Service]
ExecStart=/usr/bin/myapp
Restart=on-failure
User=myapp

[Install]
WantedBy=multi-user.target

Drop-in: дополнение юнита

Юнит из пакета правят через drop-in: обновление пакета перезапишет сам файл юнита, а drop-in останется. Drop-in — файл .conf в каталоге /etc/systemd/system/<юнит>.d/. systemd читает юнит, затем drop-in'ы по алфавиту, и их строки дополняют или заменяют строки юнита.

bash

sudo systemctl edit nginx       # редактор; сохранит override.conf
sudo mkdir -p /etc/systemd/system/demo.service.d       # или руками:
printf '[Service]\nMemoryMax=256M\n' \
  | sudo tee /etc/systemd/system/demo.service.d/memory.conf
sudo systemctl daemon-reload    # перечитать юниты после ручных правок
systemctl cat demo              # юнит и все его drop-in'ы
systemctl show demo -p DropInPaths

systemctl edit сам делает daemon-reload. После ручной правки без daemon-reload systemd работает со старой версией юнита. Ключ вроде ExecStart= в drop-in'е добавляет вторую команду; чтобы заменить первую, перед новой строкой ставят пустую ExecStart=.

Ключ в чужой секции systemd пропускает: LimitNOFILE= под [Unit] не действует, служба получает лимит по умолчанию. Предупреждение видно в журнале после daemon-reload и в systemd-analyze verify — код у него всё равно 0:

bash

systemd-analyze verify /etc/systemd/system/demo.service

text

/etc/systemd/system/demo.service:3: Unknown key name 'LimitNOFILE' in
  section 'Unit', ignoring.

Активация сокетом

Юнит .socket держит порт вместо службы: systemd слушает сам и запускает одноимённую службу при первом соединении. Учебная пара — demo-sock.socket и demo-sock.service:

ini

# /etc/systemd/system/demo-sock.socket
[Socket]
ListenStream=8085

[Install]
WantedBy=sockets.target

# /etc/systemd/system/demo-sock.service
[Unit]
Requires=demo-sock.socket
After=demo-sock.socket

[Service]
ExecStart=/usr/bin/python3 /usr/local/bin/demo-sock.py

ListenStream=8085 — только порт, без адреса: сокет слушает все адреса, IPv4 и IPv6. До первого запроса порт держит процесс systemd, служба inactive:

text

student@ubuntu:~$ sudo ss -tlnp | grep 8085
LISTEN 0  4096  *:8085  *:*  users:(("systemd",pid=1,fd=71))
student@ubuntu:~$ systemctl list-sockets | grep -E 'LISTEN|demo'
LISTEN     UNIT              ACTIVATES
[::]:8085  demo-sock.socket  demo-sock.service
student@ubuntu:~$ curl -s http://127.0.0.1:8085/
hello
student@ubuntu:~$ sudo ss -tlnp | grep 8085
LISTEN 0  4096  *:8085  *:*
  users:(("python3",pid=2769,fd=3),("systemd",pid=1,fd=71))

Адрес меняют drop-in'ом. ListenStream= — список: пустая строка сбрасывает адреса из юнита, без неё новый адрес добавится к старому.

bash

sudo mkdir -p /etc/systemd/system/demo-sock.socket.d
printf '[Socket]\nListenStream=\nListenStream=127.0.0.1:8085\n' \
  | sudo tee /etc/systemd/system/demo-sock.socket.d/local.conf
sudo systemctl daemon-reload
sudo systemctl restart demo-sock.socket
sudo ss -tlnp | grep 8085           # 127.0.0.1:8085

restart сокета перезапускает и службу с Requires= на него: MainPID службы сменился (2769 → 2838). Остановить одну службу мало — следующее соединение запустит её снова, а systemctl stop предупредит:

text

Stopping 'demo-sock.service', but its triggering units are still active:
demo-sock.socket

Закрыть порт совсем — sudo systemctl disable --now demo-sock.socket.

Цели (targets)

Цель — группа юнитов, до которой systemd доводит загрузку: multi-user.target у сервера, rescue.target и emergency.target для починки. Подробно — boot-targets.

bash

systemctl get-default              # текущая цель по умолчанию
sudo systemctl set-default multi-user.target
systemctl isolate rescue.target    # переключиться сейчас

Служба не стартует

systemctl status <unit> — код выхода и последние строки журнала.
journalctl -xeu <unit> — подробности с пояснениями.
После ручной правки юнита всегда sudo systemctl daemon-reload.

«Unit not found»

Проверь имя и путь: systemctl cat <unit>. Если правил файл — daemon-reload.

Долгая загрузка

systemd-analyze critical-chain — кто держал загрузку; порядок разбора — systemd-analyze.