Внезапное исчезновение процесса игрового сервера без сообщений об ошибках в консоли — типичная головная боль системного администратора. Сервер просто перестаёт отвечать, а в файле latest.log последней строкой оказывается обычное игровое событие. В операционной системе Linux процесс никогда не исчезает бесследно: ядро и супервизор служб всегда фиксируют код завершения, сигнал или событие нехватки памяти.
Инструкция предназначена для администраторов игровых серверов на Linux. На 28 октября 2026 года для диагностики используются стандартные средства ядра, systemd и анализ сигналов POSIX.
О чем говорит код завершения процесса#
Когда процесс завершается под управлением Linux, он возвращает числовой код завершения. Если завершение произошло по сигналу операционной системы, код рассчитывается по формуле 128 + номер сигнала:
| Код завершения | Сигнал | Типичная причина |
|---|---|---|
137 | SIGKILL (сигнал 9) | Принудительное уничтожение ядром Linux из-за Out-of-Memory (OOM Killer) или лимита памяти в Docker cgroup |
139 | SIGSEGV (сигнал 11) | Ошибка сегментации: обращение к невалидной памяти, сбойный мод или несовместимая бинарная библиотека |
143 | SIGTERM (сигнал 15) | Штатный запрос на остановку от systemd, планировщика или команды systemctl stop |
134 | SIGABRT (сигнал 6) | Аварийный отказ: сработало внутреннее утверждение (assert) в коде C++ или JVM |
1 | Общая ошибка | Ошибка синтаксиса конфигурации, занятый сетевой порт или отсутствие прав на запись |
Быстро узнать код завершения последней упавшей службы systemd можно одной командой:
systemctl show game-server.service -p Result -p ExecMainStatus -p ExecMainCode
Если статус показывает Result=oom-kill или ExecMainStatus=137, сервер был принудительно убит из-за исчерпания оперативной памяти.
Проверка журналов ядра на срабатывание OOM Killer#
Если сервер завершился с кодом 137, проверьте кольцевой буфер ядра утилитой dmesg:
sudo dmesg -T | grep -i -E 'oom[-_]killer|killed process'
При исчерпании памяти ядро выведет подробную запись с точным временем, именем процесса и объёмом выделенной памяти:
Out of memory: Killed process 41829 (RustDedicated) total-vm:18492012kB, anon-rss:14201948kB
Это прямое доказательство того, что падение вызвано не ошибкой в коде игры, а физической нехваткой RAM на хосте или жестким ограничением в cgroup/Docker.
Проверка журналов службы через journalctl#
Если ядро не фиксирует OOM Killer, проверьте стандартный поток вывода службы через journalctl:
sudo journalctl -u game-server.service -e -n 100 --no-pager
Обратите внимание на строки перед завершением процесса:
Address already in use— порт сервера уже занят другим процессом или зависшим экземпляром.Permission denied— процесс запущен от пользователя, у которого нет прав на чтение или запись в каталог мира.Failed to open descriptor— исчерпан лимит открытых файловых дескрипторов процесса (nofile).
Поиск дампов памяти при Segmentation Fault (coredumpctl)#
Если сервер падает с кодом 139 (SIGSEGV), операционная система фиксирует сбой обращения к памяти.
Проверьте наличие сохранённых дампов памяти утилитой coredumpctl:
coredumpctl list
Для просмотра информации о конкретном сбое выполните:
coredumpctl info
В блоке Stack trace вы увидите конкретную динамическую библиотеку (.so), вызвавшую сбой: это позволяет мгновенно понять, вызвана ли ошибка модом (например, расширением Metamod), системным драйвером или движком самой игры.
Если вы сопровождаете инфраструктуру игровых серверов через Nexardo, проверяйте системные лимиты памяти и параметры супервизора в едином интерфейсе: автоматический сбор телеметрии хоста помогает устранять причины падений до того, как они повторятся.
