systemd, screen и tmux для игровых процессов

MAATRIX GAMES

Запустил сервер прямо в SSH-сессии, закрыл терминал — и процесс умер вместе с сессией. Знакомая ситуация для тех, кто первый раз поднимает Rust, Minecraft или CS2 на VPS. Есть три рабочих способа держать игровой процесс в фоне: screen, tmux и systemd. У каждого свои плюсы, и часто их используют не по отдельности, а вместе — разберём, как и когда.

Почему процесс умирает при закрытии SSH

Когда вы запускаете ./start.sh или java -jar server.jar прямо в терминале, процесс привязан к вашей SSH-сессии — технически он становится дочерним процессом шелла и получает сигнал SIGHUP, как только сессия завершается. Обходной путь через nohup ./start.sh & работает, но у него есть неприятные ограничения: вы не увидите консоль сервера вживую, не сможете набрать команду save-all или stop в стандартный ввод процесса, а вывод придётся вычитывать из файла логов через tail -f nohup.out. Для разовой задачи сгодится, но для постоянной работы сервера — не вариант.

Отсюда и растут три подхода: терминальный мультиплексор (screen или tmux), который держит виртуальную сессию живой независимо от вашего подключения, и системный менеджер процессов (systemd), который управляет процессом на уровне ОС.

screen: самый простой вход в тему

screen — старый и почти всегда предустановленный инструмент (если нет — apt install screen или yum install screen). Логика простая: вы создаёте именованную сессию, запускаете в ней сервер, отсоединяетесь — сессия продолжает жить в фоне, а при следующем подключении вы возвращаетесь в неё и видите ровно ту же консоль, какой её оставили.

screen -S rust-server
cd /home/steam/rust
./RustDedicated -batchmode +server.port 28015

Отсоединиться от сессии, не убивая процесс: Ctrl+A, затем D. Вернуться позже:

screen -r rust-server

Посмотреть список активных сессий:

screen -ls

Если сессия вдруг оказалась "attached" в другом месте (например, соединение оборвалось некорректно), подключиться принудительно:

screen -d -r rust-server

Плюс screen — вы буквально видите живую консоль сервера: логи чанков, сообщения игроков, RCON-вывод, предупреждения о крашах. Минус — если сервер упадёт (например, из-за нехватки памяти или бага мода), screen сам его не перезапустит: сессия останется открытой, но пустой, а игроки будут стучаться в закрытый порт, пока вы не заметите проблему и не зайдёте руками.

tmux: тот же принцип, но гибче

tmux решает ту же задачу, что и screen, но даёт более удобную работу с несколькими окнами и панелями внутри одной сессии — полезно, если на одном VPS крутится сразу несколько игровых серверов или вы хотите держать рядом консоль сервера и, скажем, htop.

tmux new -s ark-server
cd /home/ark/server
./ShooterGameServer TheIsland?listen -server -log

Отсоединиться: Ctrl+B, затем D. Вернуться:

tmux attach -t ark-server

Список сессий:

tmux ls

Разделить окно на панели можно прямо внутри сессии: Ctrl+B % — вертикальный сплит, Ctrl+B " — горизонтальный. Удобно, когда нужно одновременно смотреть консоль сервера и, например, вывод journalctl или мониторинг нагрузки — подробнее про это в статье про мониторинг TPS и лагов.

По сути выбор между screen и tmux — дело привычки: screen проще и стоит почти везде из коробки, tmux функциональнее, но иногда требует отдельной установки. Автоперезапуска при падении процесса ни тот ни другой не даёт — это ограничение общее для обоих мультиплексоров.

systemd: автозапуск и автоперезапуск на уровне ОС

systemd — стандартный менеджер сервисов в современных дистрибутивах (Ubuntu, Debian, CentOS/AlmaLinux). Вместо ручного запуска в терминале вы описываете процесс как unit-файл, и дальше система сама следит за ним: запускает при загрузке хоста, перезапускает при падении, пишет вывод в единый журнал.

Минимальный unit-файл для игрового сервера, например /etc/systemd/system/rust-server.service:

[Unit]
Description=Rust Dedicated Server
After=network.target

[Service]
Type=simple
User=steam
WorkingDirectory=/home/steam/rust
ExecStart=/home/steam/rust/RustDedicated -batchmode +server.port 28015
Restart=always
RestartSec=10
LimitNOFILE=100000

[Install]
WantedBy=multi-user.target

Ключевая строка — Restart=always: если процесс упадёт (краш, OOM, кто-то случайно убил его через kill), systemd подождёт RestartSec секунд и поднимет сервер заново без вашего участия. Это то, чего screen и tmux не умеют сами по себе.

Применить и запустить:

systemctl daemon-reload
systemctl enable rust-server
systemctl start rust-server

Статус и логи:

systemctl status rust-server
journalctl -u rust-server -f

Полный разбор автозапуска через systemd, флагов Restart=, работы с правами пользователя и типичных грабель (например, если сервер демонизируется сам и Type=simple работает некорректно) — в отдельной статье про автозапуск игрового сервера при перезагрузке хоста. Здесь — только сравнение подходов, поэтому не дублируем детали.

Минус systemd — вы не видите живую консоль сервера так же удобно, как в screen или tmux. journalctl -u rust-server -f покажет поток логов, но набрать интерактивную команду в стандартный ввод процесса (например, RCON-команду прямо в консоли Minecraft-сервера без плагина) уже не получится — процесс запущен не в интерактивном терминале, а как системный сервис.

Сравнение подходов

Если коротко: screen/tmux — про удобство ручного управления и живую консоль, systemd — про надёжность и автоматику. Ни один из вариантов не покрывает всё сразу, и это нормально.

Комбинированный подход: systemd + screen или tmux

На практике многие держат основной запуск через systemd ради надёжности — если хост перезагрузится или сервер упадёт ночью, он поднимется сам, — а для ручного вмешательства заходят через screen или tmux, когда нужно ввести команду прямо в консоль сервера (например, save-all на Minecraft перед бэкапом или ручной RCON-вызов на Rust).

Технически совместить оба варианта можно так: вместо прямого запуска бинарника через ExecStart, systemd запускает screen-сессию с сервером внутри:

ExecStart=/usr/bin/screen -DmS rust-server /home/steam/rust/RustDedicated -batchmode +server.port 28015

Флаг -DmS создаёт detached-сессию сразу в фоне. После старта сервиса можно зайти в ту же сессию руками:

screen -r rust-server

и увидеть живую консоль — при этом systemd продолжает следить за процессом и перезапустит его при падении. Нюанс: если вы наберёте в screen-сессии команду, которая останавливает сервер изнутри (например, stop в консоли Minecraft), это будет выглядеть для systemd как штатное завершение процесса, и он тут же попытается перезапустить его согласно Restart=. Чтобы временно остановить сервер для обслуживания, правильнее сначала сделать systemctl stop rust-server, а не гасить процесс изнутри его собственной консоли.

Такая связка не единственно верная — некоторые предпочитают более "тяжёлые" решения вроде tmux с автоматическим логированием панелей или отдельные обвязки для RCON, но для большинства связок это оверинжиниринг. Если сервер регулярно падает и вы не понимаете почему, разумнее сначала разобраться в причине через логи и краш-репорты, а не полагаться только на автоперезапуск — он лечит симптом, а не причину, и на утро вы рискуете получить сервер, который перезапускался десять раз за ночь с потерей прогресса игроков каждый раз.

Частые вопросы