EQVPS

Держим бота 24/7 на VPS (чтобы он не падал молча)

Jun 15, 2026 · 2 min read · EQVPS Team

Бот «не работает» на сервере двумя способами. Очевидный: останавливается, как только вы закрываете SSH. Коварный: работает себе два дня, падает в 4 утра на каком-то необработанном исключении, и вы узнаёте об этом через часы, когда кто-то спрашивает, почему он лежит. У обоих одно решение, и это не «не забывать перезапускать» — это передать работу systemd, который держит всё живым за вас.

Почему умирает при выходе

Если запустили python bot.py в SSH-сессии, процесс — её потомок. Закрыли сессию — процесс с ней. nohup и & маскируют это, но не дают ни рестарта при падении, ни старта при загрузке — так вы решили мелкую проблему и сохранили большую.

Реальное решение: systemd-сервис

Это всё целиком. Создайте /etc/systemd/system/mybot.service:

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

[Service]
WorkingDirectory=/home/youruser/mybot
ExecStart=/home/youruser/mybot/venv/bin/python bot.py
Restart=always
RestartSec=5
User=youruser
Environment=API_KEY=...

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable --now mybot

Всю тяжёлую работу делают две строки:

Если всё ещё барахлит — читайте логи

Бот, который крэш-лупит, не чинится «перезапустить сильнее»; что-то реально не так. systemd ловит stdout/stderr, так что:

systemctl status mybot          # жив/лежит, последний код выхода
journalctl -u mybot -n 100      # свежие логи + ошибка, на которой умер
journalctl -u mybot -f          # следить вживую

Причина почти всегда прямо там: отсутствующая переменная окружения, необработанное исключение, таймаут API, OOM-kill. Чините еёRestart=always это страховка, не лекарство от реального бага.

Подсказка: если логи показывают, что бота убивают за память — вы переросли сервер, см. гайд по sizing.

Когда вместо подходят tmux или pm2

systemd не единственный ответ, просто лучший дефолт:

Для одного постоянного бота или агента systemd — самое простое, что реально работает: он уже на сервере, не требует лишних инструментов и делает рестарт, старт-при-загрузке и логирование из коробки.

Честный итог

Аптайм — не про сервер побольше или больше дисциплины, а про то, чтобы не привязывать процесс к ноутбуку. Оберните в systemd-юнит с Restart=always и enable, и смотрите journalctl, когда что-то не так. Сделайте это раз — и бот держится, смотрите вы или спите. (Новый сервер? Сначала закройте его — бот 24/7 это и мишень 24/7.)

FAQ

Почему бот останавливается при закрытии SSH?

Потому что вы запустили его внутри SSH-сессии, и он привязан к ней — умирает с отключением. Решение — запустить как фоновый сервис, независимый от вашего входа: systemd — чистый путь, tmux — быстрый.

Как авто-перезапускать бота при падении?

Запустите как systemd-сервис с Restart=always и небольшим RestartSec. systemd тогда поднимает процесс за секунды после любого падения, бесконечно, без присмотра. Эта одна строка — разница между «умер в 4 утра» и «моргнул и восстановился».

Как сделать, чтобы бот стартовал после перезагрузки?

systemctl enable вашего сервиса. «enable» привязывает старт к загрузке, «start» запускает сейчас — делайте оба (systemctl enable --now). После любой перезагрузки бот возвращается сам, без вашего входа.

systemd, pm2 или tmux — что выбрать?

systemd для всего реального и долгоживущего: рестарт, старт-при-загрузке и логирование нативно, без лишних инструментов. tmux хорош для быстрого теста или интерактивного прогона. pm2 разумен, если живёте в Node и хотите его дашборд, но это ещё один процесс, который надо держать живым. Для одного постоянного бота systemd выигрывает простотой.

Как понять, почему бот падает?

journalctl -u yourbot -n 100 показывает свежие логи и ошибку, на которой он умер; добавьте -f, чтобы следить вживую. Обычно тут и прячется реальная причина — отсутствующая переменная окружения, необработанное исключение, таймаут API. Чините её, не перезапускайте вслепую.

← Back to blogSee plans & pricing →