Зачем серверу нужен управляемый автозапуск
Запуск игрового сервера вручную через SSH подходит только для первых тестов. После перезагрузки VPS или аварийного завершения процесса сервер останется выключенным, пока владелец не подключится и не запустит его повторно.
Systemd позволяет оформить игровой процесс как системную службу. Такая служба запускается после загрузки Linux, корректно останавливается, ведёт журнал и может автоматически перезапустить сервер после сбоя.
Главное преимущество заключается не только в автоматизации. Владелец получает единый и предсказуемый способ управления:
- запуск;
- остановка;
- перезапуск;
- проверка статуса;
- просмотр последних ошибок;
- включение автозагрузки;
- временное отключение службы.
Не запускайте игровой сервер от root
Для CS2 лучше создать отдельного пользователя, например steam. Его права должны быть ограничены каталогом игрового сервера и необходимыми служебными файлами.
Запуск от root опасен по нескольким причинам. Ошибка в скрипте или стороннем плагине получает слишком широкие права, а файлы после обновления могут оказаться недоступны обычному пользователю.
Проверьте владельца папки:
/home/steam/cs2-server
Все игровые файлы, конфигурации, логи и плагины должны принадлежать тому пользователю, от имени которого работает служба.
Подготовьте команду запуска
До создания systemd-службы убедитесь, что сервер стабильно запускается обычной командой. Не пытайтесь одновременно исправлять командную строку и systemd.
Проверьте:
- путь к исполняемому файлу;
- рабочую папку;
- игровой порт;
- query-порт;
- выбранную карту;
- максимальное число игроков;
- загрузку приватной конфигурации;
- права на запись журналов.
Команду лучше вынести в отдельный скрипт запуска. Это упрощает чтение unit-файла и позволяет редактировать параметры без длинной строки внутри systemd.
Структура systemd-службы
Служба обычно содержит несколько важных разделов.
В блоке Unit указывают описание и зависимости от сети. В блоке Service задают пользователя, рабочую папку, команду запуска и политику перезапуска. В блоке Install определяют запуск при обычной многопользовательской загрузке системы.
Критически важные параметры:
User;WorkingDirectory;ExecStart;Restart;RestartSec;TimeoutStopSec;KillSignal.
Не используйте бесконечный мгновенный перезапуск. Если сервер завершается сразу после запуска из-за ошибки конфигурации, systemd может создать непрерывный цикл и заполнить журнал.
Политика автоматического перезапуска
Для игрового сервера обычно подходит перезапуск при ошибке. Задержка в несколько секунд защищает от слишком частых попыток.
Systemd должен отличать штатную остановку администратора от аварии. Если владелец выполнил команду остановки, служба не должна немедленно запускать сервер обратно.
После настройки специально завершите игровой процесс и проверьте, запустит ли systemd его повторно. Затем выполните штатную остановку службы и убедитесь, что процесс не возвращается.
Журналы systemd
Для просмотра событий используется journalctl. Там можно увидеть запуск службы, код завершения и часть вывода процесса.
Однако журнал systemd не заменяет игровые логи. Храните отдельно:
- консольный вывод;
- журналы CounterStrikeSharp;
- ошибки плагинов;
- события обновления;
- административные действия.
Настройте ротацию, чтобы журналы не заняли весь диск.
Корректная остановка
Жёсткое завершение процесса допустимо только при зависании. В обычной ситуации серверу нужно дать время записать данные и закрыть файлы.
Параметр ожидания остановки должен учитывать работу плагинов и базы данных. Слишком короткое значение приведёт к принудительному завершению до сохранения состояния.
После остановки проверьте, что процесс действительно исчез и порт освобождён. Если остаются дочерние процессы, возможно, скрипт запуска создаёт неправильную оболочку.
Автозагрузка после перезагрузки
Создать unit-файл недостаточно. Службу необходимо включить в автозагрузку.
После включения выполните реальную перезагрузку сервера в удобное время и проверьте:
- появился ли игровой процесс;
- открылся ли порт;
- загрузилась ли стартовая карта;
- работают ли плагины;
- отображается ли сервер в мониторинге.
Через несколько минут проверьте карточку сервера на cs2-monitor.com. Внешняя проверка подтверждает, что процесс не просто запущен локально, но действительно отвечает игрокам.
Связь с обновлением сервера
Не запускайте обновление SteamCMD одновременно с работающим игровым процессом. Скрипт обслуживания должен сначала остановить systemd-службу, создать резервную копию, выполнить обновление и только затем запустить сервер.
Если обновление завершилось ошибкой, автоматический запуск старой или неполной сборки может привести к циклу падений. Проверяйте код завершения SteamCMD до старта службы.
Защита от нескольких экземпляров
Systemd помогает избежать случайного запуска нескольких одинаковых процессов, но отдельный скрипт не должен отправлять команду запуска в фоне и сразу завершаться.
Исполняемый процесс должен оставаться основным процессом службы. Не используйте лишние screen, tmux и символ & внутри ExecStart, если управление полностью передано systemd.
Контроль ресурсов
В unit-файле можно ограничить ресурсы службы, но делать это нужно осторожно. Слишком жёсткое ограничение памяти или процессора вызовет лаги и аварийные завершения.
Сначала измерьте реальное потребление при полном онлайне. Затем при необходимости задайте защитные пределы, оставив разумный запас.
Итог
Systemd превращает ручной игровой процесс в управляемую службу. Сервер автоматически запускается после перезагрузки, восстанавливается после сбоя и имеет единые команды управления.
Настройте отдельного пользователя, корректную команду запуска, задержку перезапуска и журналы. После завершения обязательно проверьте реальную перезагрузку VPS и внешний ответ через мониторинг.