Запуск Python-скриптов на сервере 24/7: systemd и screen

Боты, ИИ и автоматизация
Запуск Python-скриптов на сервере 24/7: systemd и screen

Запуск Python-скрипта на сервере 24/7 — задача, с которой сталкивается каждый, кто написал парсер, бота или скрипт мониторинга: на домашнем компьютере он живёт до первой перезагрузки, а при закрытии SSH-терминала процесс на сервере просто умирает. В этой статье разберём два правильных способа держать Python на сервере круглосуточно: screen — для быстрых разовых задач, и systemd — для постоянной работы с автозапуском и перезапуском при сбоях. Все команды проверены на Ubuntu 24.04 LTS, а сервер для этого может стоить всего 59 ₽/мес.

Почему скрипт умирает при закрытии терминала

Когда вы запускаете python main.py в SSH-сессии, процесс становится дочерним по отношению к вашей оболочке. Закрыли терминал или оборвалась связь — оболочка получает сигнал SIGHUP и передаёт его всем «детям», включая ваш скрипт. Итог: скрипт работает, только пока открыт терминал.

Обойти это можно тремя способами, от кустарного к правильному:

  • nohup python main.py & — скрипт игнорирует SIGHUP, но управлять им неудобно, а после перезагрузки он не поднимется;
  • screen/tmux — «отсоединяемый» терминал: сессия живёт на сервере независимо от вашего подключения;
  • systemd — полноценная служба с автозапуском, перезапуском при падении и логами.

Подготовка: сервер и виртуальное окружение

Скрипту, который только ходит в интернет исходящими запросами (парсер, бот, мониторинг), не нужен ни входящий трафик, ни выделенный IP-адрес. Это значит, что подойдёт NAT VPS — у Cheap-Host тариф NAT Start (1 vCPU, 1 ГБ RAM, 10 ГБ NVMe, безлимитный трафик) стоит 59 ₽/мес, а сервер выдаётся автоматически за 45–60 секунд. Классический VPS с выделенным IP оправдан, только если к скрипту нужно подключаться извне — например, у него есть веб-интерфейс на стандартном порту.

Готовим окружение на Ubuntu 24.04 (там уже стоит Python 3.12):

apt update && apt install -y python3-venv python3-pip
mkdir -p /opt/myscript && cd /opt/myscript
python3 -m venv venv
./venv/bin/pip install requests

Виртуальное окружение — не формальность: Ubuntu 24.04 не даёт ставить пакеты в системный Python через pip (ошибка externally-managed-environment), так что venv — штатный путь. Кладём в каталог свой main.py и проверяем вручную:

./venv/bin/python main.py

Способ 1. Screen: быстрый запуск для разовых задач

Screen создаёт терминальную сессию, которая живёт на сервере сама по себе. Устанавливаем и запускаем:

apt install -y screen
screen -S parser
cd /opt/myscript && ./venv/bin/python main.py

Теперь главное: нажмите <kbd>Ctrl+A</kbd>, затем <kbd>D</kbd> — сессия «отсоединится», а скрипт продолжит работать. Можно закрывать терминал и выключать компьютер. Полезные команды:

screen -ls            # список сессий
screen -r parser      # вернуться в сессию
screen -XS parser quit  # завершить сессию вместе со скриптом

Ограничения screen честно перечислим:

  • после перезагрузки сервера сессии не восстанавливаются;
  • упавший скрипт никто не перезапустит;
  • логи остаются в буфере сессии, искать в них что-то за прошлую неделю неудобно.

Вывод: screen хорош для задач на часы — «запустил миграцию и ушёл спать». Для работы неделями нужен systemd.

Способ 2. Systemd: правильный запуск скрипта 24/7

systemd — это менеджер служб, который управляет всеми демонами Linux, от SSH до Nginx. Ваш скрипт может стать такой же службой. Создаём unit-файл /etc/systemd/system/myscript.service:

[Unit]
Description=My Python script
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/myscript
Environment=PYTHONUNBUFFERED=1
ExecStart=/opt/myscript/venv/bin/python /opt/myscript/main.py
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Разбор ключевых строк:

  • ExecStart указывает на Python из venv — активация окружения не нужна;
  • Restart=always + RestartSec=10 — перезапуск через 10 секунд после любого падения;
  • PYTHONUNBUFFERED=1 — вывод print() попадает в лог сразу, без буферизации;
  • After=network-online.target — скрипт стартует после появления сети, что критично для парсеров и ботов.

Активируем:

systemctl daemon-reload
systemctl enable --now myscript
systemctl status myscript

Готово: скрипт работает 24/7, переживает перезагрузки и сам поднимается после ошибок. Управление стандартное: systemctl restart myscript, systemctl stop myscript. Про тонкости юнитов — отдельная статья о создании своих служб systemd.

Логи: journalctl вместо print в никуда

Всё, что скрипт пишет в stdout/stderr, systemd складывает в журнал:

journalctl -u myscript -f              # в реальном времени
journalctl -u myscript --since today   # за сегодня
journalctl -u myscript -p err          # только ошибки

Чтобы журнал не съел диск на маленьком тарифе, проверьте лимит в /etc/systemd/journald.conf (параметр SystemMaxUse=200M) — на 10 ГБ NVMe это разумная страховка.

А если скрипт нужен не постоянно, а по расписанию?

Частая ошибка — держать процесс живым 24/7 с циклом while True: ... time.sleep(21600). Если скрипт должен отрабатывать раз в час или раз в сутки, правильнее запускать его по расписанию через cron:

crontab -e
# каждые 6 часов:
0 */6 * * * /opt/myscript/venv/bin/python /opt/myscript/main.py >> /var/log/myscript.log 2>&1

Так скрипт не занимает память между запусками, а упавший запуск не блокирует следующий. Подробности — в статье про настройку cron-задач по расписанию.

Сравнение способов

Критерийscreensystemdcron
Переживает разрыв SSHДаДаДа
Автозапуск после rebootНетДаДа (по расписанию)
Перезапуск при паденииНетДаПри следующем запуске
Удобные логиНетjournalctlРучной redirect
СценарийРазовая задача на часыПостоянный процессПериодические задачи

Типичные постоянные процессы — это как раз боты: посмотрите практические инструкции по развёртыванию Telegram-бота и Discord-бота на VPS — там systemd используется ровно по этой схеме.

FAQ

Что лучше для запуска скрипта 24/7 — screen или systemd?

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

Переживёт ли скрипт в screen перезагрузку сервера?

Нет. Screen спасает только от разрыва SSH. После reboot все screen-сессии исчезают, и скрипт придётся запускать вручную. Автозапуск даёт только systemd (или cron с @reboot).

Какой VPS нужен для круглосуточного Python-скрипта?

Большинству скриптов — парсеры, боты, мониторинг — хватает 1 vCPU и 1 ГБ RAM. Если скрипт не принимает входящие соединения, выделенный IP не нужен, и подойдёт NAT VPS: у Cheap-Host тариф NAT Start стоит 59 ₽/мес.

Как запускать скрипт не постоянно, а по расписанию?

Через cron или systemd-таймеры. Строка 0 /6 в crontab запустит скрипт каждые 6 часов — держать процесс в памяти между запусками не нужно.

Куда пишутся print() из скрипта под systemd?

В журнал systemd: journalctl -u имя_службы -f. Чтобы вывод появлялся сразу, а не буферизовался, добавьте в unit-файл Environment=PYTHONUNBUFFERED=1.

Вывод

Запуск Python на сервере 24/7 сводится к простому правилу: screen — для разовых задач, systemd — для всего, что должно работать всегда, cron — для запусков по расписанию. Один unit-файл на десять строк даёт то, чего не даст ни один домашний компьютер: автозапуск, самовосстановление и логи в одном месте. А поскольку типичному скрипту не нужны ни входящий трафик, ни выделенный IP, сервер для него — самый дешёвый в линейке. Если для этой задачи нужен сервер — у Cheap-Host есть NAT Start от 59 ₽/мес: NVMe, KVM, безлимитный трафик и выдача за минуту, а при росте аппетитов скрипта тариф апгрейдится без потери данных.

Читайте также