Как я автоматизировала перезапуск сервисов на VPS с помощью systemd (и почему без этого нельзя)

Однажды у меня на проде «упал» процесс, и это случилось как раз в пятницу вечером — конечно же, я уже отключилась от работы. Сайт, завязанный на этом процессе, просто перестал отвечать. И всё это время, пока я пила чай и смотрела сериал, никто не понимал, что случилось. В понедельник — ах да, извините, забыли поставить авто‑перезапуск в

. Больше таких ситуаций я себе не позволяла.

Сегодня расскажу, как настроить auto-healing на VPS с помощью systemd, чтобы сервисы сами восстанавливались при сбоях. Подойдёт для Ubuntu, Debian, CentOS — везде, где есть

.

---

Зачем вообще нужен auto-healing?

Если приложение или скрипт внезапно упал, а вы об этом узнаёте спустя сутки — это упущенные пользователи, ошибки в логах и стресс. Особенно если VPS используется для:

• микросервисов,
• веб-серверов (nginx, Apache),
• прокси,
• Telegram-ботов,
• VPN-сервисов (WireGuard, OpenVPN),
• cron-скриптов.

Решение —

и несколько строчек, которые буквально спасают прод.

---

Пример из моей практики: auto-restart для Node.js

У меня был простой сервис на Node.js, который обрабатывал API-запросы. Иногда он крашился при особых типах данных, пока я не нашла баг. Чтобы не ждать, пока я починю всё, я добавила auto-restart в его юнит:

Копировать[Unit]
Description=My Node.js API
After=network.target

[Service]
ExecStart=/usr/bin/node /home/myuser/my-api/index.js
Restart=on-failure
RestartSec=5
StartLimitBurst=3
StartLimitIntervalSec=60
User=myuser
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

Сохраняем файл как

.

Теперь, если процесс “падает”,

перезапускает его через 5 секунд. А если он упадёт 3 раза за минуту — перезапуск приостанавливается (защита от бесконечного цикла).

---

Расшифровка параметров:

• КопироватьRestart=on-failure
  — перезапускать, если процесс завершился с ошибкой.
• КопироватьRestartSec=5
  — ждать 5 секунд перед перезапуском.
• КопироватьStartLimitBurst=3
  и
  КопироватьStartLimitIntervalSec=60
  — максимум 3 перезапуска за 60 секунд.
• КопироватьExecStart
  — путь до исполняемого файла.

Также поддерживаются другие значения

, например:

Параметр	Что означает
Копироватьno	Не перезапускать (по умолчанию)
Копироватьalways	Перезапускать всегда, даже при Копироватьexit 0
Копироватьon-failure	Только если завершилось с ошибкой
Копироватьon-abnormal	Только при сигнале или core dump
Копироватьon-watchdog	При watchdog timeout
Копироватьon-abort	Только если завершено сигналом

---

Как отследить ошибки:

Копироватьsystemctl

и логи

После настройки можно наблюдать поведение:

Копироватьsudo systemctl status my-api

Если хотите увидеть, почему сервис «упал» — смотрим:

Копироватьjournalctl -u my-api

Если сервис упал слишком часто, и systemd его «заморозил», нужно сбросить счётчик:

Копироватьsudo systemctl reset-failed my-api

---

Ещё примеры из жизни

Telegram-бот

Копировать[Service]
ExecStart=/usr/bin/python3 /home/user/bot/main.py
Restart=always
RestartSec=10

WireGuard туннель

Копировать[Service]
ExecStart=/usr/bin/wg-quick up wg0
ExecStop=/usr/bin/wg-quick down wg0
Restart=on-failure
RestartSec=3

Прокси на Go

Копировать[Service]
ExecStart=/usr/local/bin/myproxy
Restart=always
RestartSec=5
User=proxyuser

---

systemd health-check (ждём как родного)

Если вы хотите ещё более продвинуто — можно настроить

и использовать , чтобы приложение «пинговало» systemd и показывало, что оно живо. Но это уже для тех, кто пишет свои сервисы с .

---

Вопрос: а что если VPS ребутнулся?

Тогда просто добавьте:

Копировать[Install]
WantedBy=multi-user.target

И выполните:

Копироватьsudo systemctl enable my-api

Теперь сервис запустится при старте системы.

---

В результате…

Если бы мне кто-то сказал ещё на старте моей практики, что одна строчка

избавит от десятков часов головной боли… я бы настроила её везде сразу. Теперь на всех VPS, где у меня крутятся сервисы, я обязательно прописываю auto-restart через . Это просто, надёжно и по-настоящему спасает.