⌛️ Автозапуск сервисов в systemd при сбоях

В systemd есть встроенный механизм автоматического перезапуска сервисов при их падении. Управляется это параметром Restart в разделе [Service] unit-файла.

📌 Основные значения Restart

always - перезапуск всегда (даже при корректном завершении)
on-success – только если сервис завершился без ошибок
on-failure – при ошибках или принудительном завершении (SIGKILL, timeout)
on-abnormal – при завершении сигналом или зависании
on-abort – если сервис был принудительно завершён
on-watchdog – при срабатывании watchdog timeout
no – автозапуск отключен (значение по умолчанию)

⚙️ Настройка автозапуска сервиса
Редактировать основной unit-файл не нужно. Достаточно создать override.conf:

mkdir -p /etc/systemd/system/nginx.service.d
nano /etc/systemd/system/nginx.service.d/override.conf

Добавьте настройки:

[Service]
Restart=always
RestartSec=5s

Примените изменения:

systemctl daemon-reload

Теперь при падении Nginx перезапустится через 5 секунд. Проверка:

systemctl status nginx
kill -9 <PID>
systemctl status nginx

🌟 Когда не стоит включать автозапуск:

1. Базы данных (MySQL, PostgreSQL) – после аварии могут запустить ресурсоёмкое восстановление, которое OOM-killer прервёт, создавая бесконечный цикл.
2. Кластеры (Elasticsearch, Ceph) – возможна рассинхронизация или некорректная работа.

Для веб-серверов (Nginx, Apache), почтовых сервисов (Postfix, Dovecot) и агентов мониторинга (Zabbix Agent) – автозапуск обычно безопасен.

✉️ Оповещения о сбоях
Добавьте в override.conf, чтобы получать уведомления:

[Unit]
OnFailure=your-notify-script.service

Это может быть скрипт с отправкой алерта в Telegram или email.

#linux #systemd

🧑‍💻 NetworkAdmin

Автоматическое монтирование дисков в Linux через systemd

Многие по привычке используют fstab для автоподключения дисков в линукс. Но systemd предлагает более гибкий и надёжный механизм - монтирование через unit-файлы.

Это особенно полезно:

📍 в средах с динамически подключаемыми дисками
📍 при работе с нестабильными устройствами (например, сетевыми томами)
📍 для точного контроля зависимостей и порядка монтирования

▪️ Пример: монтируем диск /dev/sdb1 в /mnt/data

1️⃣ Создаём unit-файл для монтирования:

sudo systemctl edit --force --full mnt-data.mount

Пример содержимого:

[Unit]
Description=Монтирование диска в /mnt/data
After=network.target

[Mount]
What=/dev/sdb1
Where=/mnt/data
Type=ext4
Options=defaults

[Install]
WantedBy=multi-user.target

Обратите внимание: имя unit-файла mnt-data.mount формируется по пути монтирования: /mnt/data → mnt-data.mount

2️⃣ Активируем и проверяем

sudo systemctl daemon-reexec
sudo systemctl enable mnt-data.mount
sudo systemctl start mnt-data.mount

Проверим статус:

systemctl status mnt-data.mount

⭐️ Преимущества systemd-монтажа:

📍 Учитываются зависимости (можно настроить Requires= и After=)
📍 Возможность рестартов и таймаутов
📍 Удобство в контейнерах и виртуальных средах
📍 Логирование и отладка через journalctl

🌟 Важно: если диск может не быть доступен при загрузке, рассмотрите опции nofail или отложенное монтирование через automount.

#linux #systemd

🧑‍💻 NetworkAdmin

🕘 Systemd timers против cron

Systemd timers - это более современный и гибкий способ планирования задач в linux, особенно на серверах с systemd.

🌟 Почему systemd timers лучше cron?

📍 Логирование по умолчанию - systemd записывает stdout/stderr задачи в journal, не нужно вручную перенаправлять вывод
📍 Зависимости и условия запуска - можно привязать таймер к другим сервисам, целям (targets) и условиям
📍 Точный контроль времени и интервалов - есть OnCalendar, OnBootSec, OnUnitActiveSec и другие
📍 Простой мониторинг - можно посмотреть статус задачи: когда запускалась, сколько длилась, когда запустится снова
📍 Юзер-таймеры - можно создавать таймеры без root-доступа для отдельных пользователей

▪️ Как настроить systemd timer. Создаем два юнита: *.service (что запускать) и *.timer (когда запускать).

Пример: бэкап в /var/backups каждую ночь в 3:00

vi /etc/systemd/system/backup.service

[Unit]
Description=Nightly backup

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

vi /etc/systemd/system/backup.timer

[Unit]
Description=Run backup script daily at 3AM

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

Активируем:

sudo systemctl daemon-reexec
sudo systemctl enable --now backup.timer

▪️ Проверить статус:

systemctl list-timers
systemctl status backup.timer
journalctl -u backup.service

▪️ Другие примеры таймеров. Через 5 минут после загрузки:

[Timer]
OnBootSec=5min

Каждые 15 минут:

[Timer]
OnUnitActiveSec=15min

Каждый понедельник в 6 утра:

[Timer]
OnCalendar=Mon *-*-* 06:00:00

▪️ Полезное:

📍 Устанавливайте Persistent=true, чтобы таймер отработал, даже если система была выключена в момент запуска
📍 Используйте systemctl cat для просмотра активных юнитов
📍 Для задач от пользователя используйте ~/.config/systemd/user/

#systemd #cron

🧑‍💻 NetworkAdmin

📄 Разделение логов по уровням и сервисам с systemd-journald

Если вы работаете на современном дистрибутиве linux, то почти наверняка используете systemd, а значит - и journald для сбора логов. Это система логирования, которая умеет куда больше, чем просто показывать логи командой journalctl. Сегодня - о том, как удобно фильтровать и разделять логи по уровню важности (info, warning, error и т.д.) и сервисам, чтобы быстро находить нужную информацию.

▪️ Фильтрация логов по юниту. Чтобы посмотреть логи конкретного сервиса:

journalctl -u nginx.service

Добавьте -b для вывода только с текущей загрузки:

journalctl -u ssh.service -b

▪️ Логи по уровню важности. Вы можете указать минимальный уровень важности:

journalctl -p err  # Только ошибки и критичнее

Список уровней (от менее к более важным):

0: emerg
1: alert
2: crit
3: err
4: warning
5: notice
6: info
7: debug

Пример: показать все warning и выше от sshd:

journalctl -u ssh.service -p warning

▪️ Ограничение по времени. Чтобы не утонуть в огромных логах:

journalctl --since "1 hour ago"
journalctl --since "2025-09-18" --until "2025-09-19 03:00"

▪️ Разделение логов по каталогам. По умолчанию journald пишет в /run/log/journal (в RAM), если /var/log/journal отсутствует. Чтобы сохранять логи между перезагрузками:

mkdir -p /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald

▪️ Настройка persist-логирования и лимитов. В файле /etc/systemd/journald.conf можно настроить:

Storage=persistent
SystemMaxUse=500M
RuntimeMaxUse=100M
MaxRetentionSec=7day

После правок - перезапустите journald:

systemctl restart systemd-journald

▪️ Глубокие фильтры. Вывести только ошибки от ядра:

journalctl _TRANSPORT=kernel -p err

Фильтр по PID:

journalctl _PID=1234

По имени бинарника:

journalctl _COMM=nginx

#logs #systemd

🧑‍💻 NetworkAdmin

👀 Смотрим логи systemd через браузер

Systemd умеет не только собирать и хранить логи, но и отдавать их по HTTP. Для этого есть служба systemd-journal-gatewayd, которая позволяет просматривать журнал прямо в браузере. Настраивается все буквально в пару шагов (пример для debian).

▪️ Установка и запуск. Устанавливаем пакет:

apt install systemd-journal-remote

Запускаем службу:

systemctl start systemd-journal-gatewayd.service

По умолчанию используется порт 19531.

▪️ Просмотр логов. Обзор всех логов:

http://10.25.1.55:19531/browse

Только логи текущей загрузки:

http://10.25.1.55:19531/entries?boot

В интерфейсе удобно переключаться между сервисами через выпадающий список.

▪️ Работа через curl. Те же данные можно забирать в JSON-формате. Например, логи для ssh.service:

curl --silent -H 'Accept: application/json' \
  'http://10.25.1.55:19531/entries?UNIT=ssh.service'

▪️ Логи с удаленных машин. systemd-journal-gatewayd умеет работать не только с локальным журналом, но и с логами, собранными с других серверов. Для этого можно указать директорию с журналами:

systemd-journal-gatewayd -D /path/to/logs

#systemd #logs

🧑‍💻 NetworkAdmin

❌ Отключение лишних сервисов через systemd

Одна из полезных практик на пути к оптимизации - переодически смотреть, а что вообще запускается и что из этого действительно нужно, а что можно отключить. Это будет полезно не только для оптимизации, но и для безопасности тоже.

1️⃣ Смотрим активные сервисы

systemctl list-unit-files --state=enabled

Команда покажет список всех юнитов, которые стартуют при загрузке. Также полезно посмотреть реально работающие процессы:

systemctl list-units --type=service

2️⃣ Отключение ненужного. Чтобы сервис не запускался при старте системы:

systemctl disable avahi-daemon.service

Чтобы остановить прямо сейчас:

systemctl stop avahi-daemon.service

Если сервис не нужен вообще - можно замаскировать, чтобы исключить случайный запуск:

systemctl mask avahi-daemon.service

(при этом запуск будет невозможен даже вручную, пока не сделаете unmask).

Примеры сервисов, которые часто не используются:

avahi-daemon.service - autodiscovery (не нужен на сервере)
bluetooth.service - если нет блютуза
ModemManager.service - если не используется мобильный модем
rpcbind.service - устаревший RPC, не нужен большинству

Далее уже зависит конкретно от Ваших потребностей и ситуации.

3️⃣ Проверка. После внесенных изменений убедитесь, что лишние службы не стартуют:

systemctl list-unit-files --state=enabled

#linux #systemd

🧑‍💻 NetworkAdmin

✏️ Шпаргалка по journalctl

journalctl - это инструмент работы с логами systemd.

▪️ Фильтрация по сервисам и юнитам. Посмотреть логи конкретной службы:

journalctl -u ssh
journalctl -u nginx -u php-fpm

Последние записи сервиса в реальном времени (аналог tail -f):

journalctl -u nginx -f

▪️ Ограничение по времени. Фильтрация по временным промежуткам:

journalctl --since "2025-10-01" --until "2025-10-15"
journalctl --since "1 hour ago"
journalctl --since yesterday

▪️ Поиск по ключевым словам. Просто используем grep:

journalctl -u ssh | grep "Failed password"

Или встроенный фильтр по приоритету (severity):

journalctl -p err -u ssh

(-p принимает диапазон: -p warning..crit)

▪️ Логи текущей загрузки

journalctl -b        # текущая загрузка
journalctl -b -1     # предыдущая загрузка
journalctl -b -2     # еще раньше

▪️ Работа с логами как с файлами

Сохранить в файл:

journalctl -u nginx --since today > nginx.log

Экспорт в бинарный лог и перенос на другой сервер:

journalctl --vacuum-time=7d   # удалить старше 7 дней
journalctl --vacuum-size=1G   # ограничить объем

#systemd #journalctl

🧑‍💻 NetworkAdmin

🕘 Оптимизация загрузки системы

Один из частых вопросов: почему система грузится так долго? Для раскрытия этой тайны можно использовать встроенный инструмент systemd-analyze, который покажет подробную статистику загрузки и поможет найти узкие места.

▪️ Базовый анализ времени загрузки. Простейшая команда:

systemd-analyze

Пример вывода:

Startup finished in 2.351s (kernel) + 8.512s (userspace) = 10.863s

kernel - время работы ядра до запуска systemd
userspace - запуск сервисов и инициализация systemd
итоговое время загрузки

▪️ Кто тормоз? Чтобы узнать, какие юниты грузились дольше всего:

systemd-analyze blame

Вывод отсортирован по времени запуска. На первых строках будут виновники торжества.

▪️ Граф зависимостей. Для наглядности можно построить диаграмму загрузки:

systemd-analyze critical-chain

Она покажет цепочку сервисов, которые напрямую влияют на общее время старта.

Для детального графа в SVG:

systemd-analyze plot > boot.svg

Файл можно открыть в браузере - это визуализация всех юнитов и их зависимостей.

▪️ Оптимизация

1️⃣ Отключить ненужные сервисы

systemctl disable bluetooth.service
systemctl disable cups.service

2️⃣ Использовать systemd-analyze blame для точечной оптимизации
Например, если дольше всего грузится NetworkManager-wait-online.service, можно сократить или отключить ожидание сети.

3️⃣ Параллелизация загрузки. systemd умеет запускать независимые сервисы параллельно, поэтому полезно проверять зависимости в systemd-analyze critical-chain.

4️⃣ Использовать mask для блокировки ненужных юнитов

systemctl mask service_name

#systemd #boot

🧑‍💻 NetworkAdmin

🧑‍💻 Создание и отладка собственных сервисов

Systemd давно стал стандартом для запуска, управления и наблюдения за сервисами. Но многие используют его только для управления уже существующими демонами и не создают собственные unit-файлы, а ведь это удобный способ автоматизировать любые скрипты, фоновые процессы или приложения.

▪️ Шаг 1: создаём unit-файл. Все пользовательские сервисы кладутся в:

/etc/systemd/system/

Пример простого сервиса, который запускает bash-скрипт:

/etc/systemd/system/myapp.service

[Unit]
Description=My custom app
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/myapp.sh
Restart=on-failure
User=myuser
Group=myuser

[Install]
WantedBy=multi-user.target

Несколько рекомендаций по параметрам:

Type=simple - подходит для скриптов и обычных демонов
Restart=on-failure - перезапуск при сбоях
User=… - всегда запускайте сервисы НЕ от root, если это возможно
After=network.target - ожидаем сеть перед запуском

▪️ Шаг 2: корректно пишем исполняемый скрипт. Для стабильной работы сервисов:

указываем shebang (#!/bin/bash);
используем абсолютные пути к бинарникам;
перенаправляем вывод в syslog или файл (если нужно);
завершаемся с кодами ошибок.

Пример:

#!/bin/bash
set -e

echo "Service started"
ping -c 1 8.8.8.8

Не забываем:

chmod +x /usr/local/bin/myapp.sh

▪️ Шаг 3: включаем и запускаем сервис

systemctl daemon-reload
systemctl enable --now myapp.service

Проверяем статус:

systemctl status myapp.service

▪️ Отладка. Systemd имеет отличные инструменты диагностики.

Посмотреть логи сервиса:

journalctl -u myapp.service -f

Проверить последнюю ошибку:

systemctl status myapp.service

Проверить, что systemd видит изменения:

systemctl daemon-reload

Принудительно перезапустить сам процесс:

systemctl restart myapp.service

▪️ Полезные параметры, которые часто забывают

LimitNOFILE - увеличить максимальное количество файлов
LimitNOFILE=65535

WorkingDirectory - задать рабочую директорию
WorkingDirectory=/opt/myapp

Environment - задать переменные окружения
Environment="APP_ENV=prod"

▪️ Безопасность. Systemd умеет частично изолировать сервисы, похожим образом на контейнеры, например:

ProtectSystem=full
ProtectHome=true
PrivateTmp=true
NoNewPrivileges=true

#linux #systemd

🧑‍💻 NetworkAdmin

🔠 Монтирование файловых систем через systemd

Хотя многие админы по привычке используют /etc/fstab, у systemd есть собственный механизм монтирования, который во многом удобнее и современнее.

📍 Почему systemd лучше, чем fstab?

1️⃣Автомонтирование при обращении - устройство подключается только тогда, когда к нему обращаются, и может автоматически отключаться по заданному таймауту.
2️⃣Автосоздание точек монтирования - systemd сам создает нужные директории, администратору не нужно следить за их наличием.
3️⃣Гибкая работа с таймаутами - если устройство недоступно, загрузка системы не повиснет, как это иногда бывает с fstab.
4️⃣Зависимости от сервисов - можно задать, что монтирование произойдёт только после старта VPN или другого сервиса, который необходим для доступа к диску.

▪️ Пример: локальный диск в /mnt/backup

1️⃣ Создаем юнит /etc/systemd/system/mnt-backup.mount:

[Unit]
Description=Disk for backups

[Mount]
What=/dev/disk/by-uuid/f774fad3-2ba0-47d1-a20b-0b1c2ae1b7d6
Where=/mnt/backup
Type=ext4
Options=defaults

[Install]
WantedBy=multi-user.target

2️⃣ Подготовка диска:

cfdisk /dev/sdb #создаем раздел
mkfs -t ext4 /dev/sdb1  #форматируем
blkid #смотрим UUID

3️⃣ Запуск и включение автозагрузки:

systemctl daemon-reload
systemctl start mnt-backup.mount
systemctl enable mnt-backup.mount

▪️ Пример: автомонтирование NFS через VPN. Для сетевых дисков будет удобнее использовать .automount. Он подключает ресурс по требованию и может отмонтировать при простое.

/etc/systemd/system/mnt-backup.mount:

[Unit]
Description=NFS share

[Mount]
What=srv.example.com:/backup/nfs_share
Where=/mnt/backup
Type=nfs4
Options=rw
TimeoutSec=15

/etc/systemd/system/mnt-backup.automount:

[Unit]
Description=NFS share
Requires=network-online.target
BindsTo=openvpn@client.service
After=openvpn@client.service

[Automount]
Where=/mnt/backup
TimeoutIdleSec=60

[Install]
WantedBy=graphical.target

Включаем:

systemctl daemon-reload
systemctl enable --now mnt-backup.automount

Теперь:

при старте системы диск не монтируется сразу;
при первом обращении к /mnt/backup - идет подключение NFS через VPN;
при остановке openvpn@client.service диск автоматически отмонтируется.

#systemd #fstab

🧑‍💻 NetworkAdmin