Если процесс Terraria сразу завершается, открытый firewall его не запустит. Сначала сохраните первую ошибку и определите этап: Linux не смог выполнить программу, runtime не загрузился, сервер не открыл мир или уже работающий процесс был завершён.
Статья относится к vanilla PC dedicated server на Linux. В примерах используются /opt/terraria/server, пользователь terraria и terraria.service; замените их своими путями и механизмом запуска. У TShock и tModLoader другие runtime: инструкции по их установке нельзя автоматически переносить на vanilla.
Сохраните неудачную попытку#
Для systemd сначала получите действующий unit и сообщения текущей загрузки. Не очищайте ошибочное состояние и не устанавливайте пакеты до сбора сведений:
sudo systemctl status terraria.service --no-pager
sudo systemctl cat terraria.service
sudo journalctl -u terraria.service -b --no-pager -n 150
sudo systemctl show terraria.service -p Result -p ExecMainCode -p ExecMainStatus -p NRestarts
В журнале может повторяться цикл рестартов. Найдите первую ошибку приложения внутри одной попытки, а не только последнее сообщение об исчерпании лимита запусков. Сохраните вывод у себя, затем остановите сервис, чтобы он не продолжал новые попытки во время диагностики. Не запускайте вручную второй процесс на мир, с которым первый ещё работает.
Например, 203/EXEC означает, что systemd не смог выполнить указанную программу. Но если ExecStart запускает Bash или другую оболочку, она может успешно открыться, а затем вывести отдельную ошибку дочернего процесса. Читайте и unit, и его реальный вывод.
Сравните файл и процессор до установки runtime#
Проверьте именно тот бинарник, который указан в команде запуска. При необходимости установите file и binutils из репозитория своего дистрибутива:
uname -m
file /opt/terraria/server/TerrariaServer.bin.x86_64
readelf -l /opt/terraria/server/TerrariaServer.bin.x86_64
namei -l /opt/terraria/server/TerrariaServer.bin.x86_64
findmnt -T /opt/terraria/server/TerrariaServer.bin.x86_64
Исполняемый файл Linux x86-64 не становится ARM64-файлом от того, что обе системы 64-битные. Raspberry Pi с 64-битной ОС может показывать aarch64; право выполнения не переводит машинные инструкции. Нужен подтверждённо поддерживаемый путь запуска выбранной серверной сборки или перенос vanilla на совместимую машину. Это смена архитектуры, а не исправление прав.
Разберите точное сообщение:
| Наблюдение | Что проверить и сделать |
|---|---|
Permission denied | Право выполнения файла, проход по родительским каталогам, noexec у монтирования и запреты политики безопасности. Исправляйте конкретный отказ. |
Exec format error | Архитектуру процессора и формат файла; убедитесь, что выбран Linux-дистрибутив, а не Windows-программа. |
No such file or directory, хотя бинарник существует | ELF-интерпретатор в выводе readelf: ошибка бывает и при отсутствии загрузчика. У скрипта проверьте интерпретатор в shebang и окончания строк. |
Отсутствует .so или GLIBC_… not found | Совместимость указанной библиотеки или libc с дистрибутивом и архитектурой. Не подставляйте случайный файл библиотеки. |
Выдавайте выполнение адресно: например, chmod u+x, если запускающий пользователь владеет доверенным бинарником. Если владелец — администратор, а сервис запускается другим пользователем, может подходить контролируемый администратором режим 0755. Команда chmod 777 расширяет возможность записи и не устраняет ни несовместимость архитектуры, ни отсутствие загрузчика.
Сохраняйте серверную сборку целиком#
Для доверенного официального дистрибутива можно посмотреть разрешение связанных библиотек:
ldd /opt/terraria/server/TerrariaServer.bin.x86_64
Используйте ldd только с доверенным исполняемым файлом. Отсутствие ошибок здесь ещё не доказывает доступность всех managed-сборок и библиотек, загружаемых позже. Нужен полный Linux-каталог одной версии, а не только главный бинарник. Если обновление смешало старые и новые файлы, распакуйте подходящий чистый релиз в другой каталог, сохраните прежнюю установку и копию мира, затем перенаправьте запуск на полный новый комплект.
Не устанавливайте случайную версию Mono или .NET только потому, что её упомянули на форуме. Удаление комплектных System* или Mono* тоже может превратить понятную несовместимость в другую поломку. Ориентируйтесь на требования именно вашего серверного пакета. Ошибка инициализации консоли или терминала — отдельная ветка: сравните TERM сервиса с поддерживаемым окружением запуска, не меняя сразу игровые файлы.
Меню выбора мира не означает исправный автозапуск#
Если сервер предлагает выбрать мир или ввести порт, проверьте -config, абсолютный путь и доступ от пользователя сервиса. Отсутствующая конфигурация может вернуть интерактивную настройку вместо ожидаемого отказа. Отдельно проверьте выбранный мир:
sudo -u terraria test -r /etc/terraria/serverconfig.txt
sudo -u terraria test -r /srv/terraria/worlds/main.wld
sudo -u terraria test -w /srv/terraria/worlds/main.wld
sudo -u terraria test -w /srv/terraria/worlds
namei -l /srv/terraria/worlds/main.wld
df -h /srv/terraria/worlds
df -i /srv/terraria/worlds
Успешный test ничего не печатает, неуспешный возвращает ненулевой код. Проверки помогают найти обычные проблемы прав, свободного места и inode, но не отменяют read-only-монтирование или обязательные политики доступа. Сверьте фактический путь мира и HOME сервиса, а не мир, видимый вашему SSH-пользователю. До восстановления конкретного мира сохраните его остановленную копию; не включайте autocreate, чтобы скрыть отсутствие файла.
При сообщении о занятом адресе посмотрите sudo ss -ltnp 'sport = :7777'. Найдите владельца сокета и оставьте один процесс либо выделите второму отдельные порт и мир. Если мир загрузился, порт слушается, но клиент получает отказ из-за версии, переходите к совместимости и подключению: это уже другой этап, чем выполнение Linux-программы.
Подтвердите нехватку памяти фактами#
Сообщение Killed, сигнал 9 или код оболочки 137 говорят о завершении, но сами по себе не называют причину. Посмотрите сообщения ядра для той же загрузки и времени инцидента:
sudo journalctl -k -b --since '20 minutes ago' --no-pager
sudo systemctl show terraria.service -p Result -p MemoryMax -p EffectiveMemoryMax -p MemoryCurrent -p ControlGroup
Ищите совпадение процесса, времени и сообщения out-of-memory. В cgroup v2 значение ControlGroup указывает каталог группы внутри /sys/fs/cgroup; пока он существует, посмотрите там memory.events. Рост oom_kill отражает убийства процессов этой группы механизмом OOM, но старое значение счётчика без сравнения «до/после» не датирует конкретный случай. У остановленного сервиса группа уже может исчезнуть.
Свободная память всей машины не определяет доступный сервису объём: меньший лимит бывает у unit, контейнера или родительской группы. Обратное тоже верно: недоступная или несохранённая история ядра не доказывает отсутствие OOM. До изменения ресурсов сохраните результат сервиса, сведения ядра и установленные ограничения. Для нескольких собственных VPS Nexardo помогает собрать работу с инфраструктурой в одном месте, но диагноз всё равно опирается на данные конкретного процесса и хоста.
После одного обоснованного изменения запустите один экземпляр и прочитайте первые сообщения. Проверьте вход совместимым клиентом в ожидаемый мир, затем — сохранение узнаваемого изменения после обычного save/restart. Если нужна помощь, приложите первоначальную ошибку, версию сборки и пути без секретов; пароль из конфигурации удалите.
