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

От GRUB до target: как загружается система

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

Шаг 7 из 8 · лаба · 25 мин

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

После каждой перезагрузки склад полминуты ждёт, а приём заказов так и не поднимается — руками его потом запускают. Коллега уверяет, что зависимости служб настроены. Сделай так, чтобы после перезагрузки приём заказов поднимался сам и не задерживал загрузку.

Ситуация

На складском сервере работают две службы: приём заказов 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 с — ещё не выполнена

Ctrl+Enter

Запустит машину node1 · Ubuntu 24.04

Машина запускается

Подсказки

0 из 3

Сообщить о проблеме

Цели лабы

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 с — ещё не выполнена

node1 Ubuntu 24.04

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

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

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

Цели лабы

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 с — ещё не выполнена

Службы и 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.