Project Zomboid сървърите могат да се сриват или да не се стартират по няколко добре известни причини. Това ръководство покрива най-честите причини, наблюдавани при тикетите за поддръжка на Legion Hosting — от бъг с паметта в Build 42, който изисква допълнителна RAM при стартиране, до препълване на резервни копия, което запълва /tmp, до повредени конфигурационни файлове. Преминете през секциите по-долу по ред.

Преди да започнете — Намерете логовете за сривове

Почти всеки срив на Project Zomboid оставя следи на едно от две места. Проверете и двете, преди да опитате каквато и да е поправка, за да знаете коя секция от това ръководство се отнася за вас.

Изход на конзолата на GPanel

1. Влезте в GPanel.
2. Изберете вашия Project Zomboid сървър от списъка със сървъри.
3. Кликнете върху раздела Console.
4. Превъртете до дъното на изхода. Потърсете редове, маркирани с ERROR, FATAL, OutOfMemoryError или Exception. Последните 20–30 реда преди сървърът да спре обикновено са най-важни.
5. Ако конзолата е празна, процесът на сървъра е приключил, преди да успее да напише нещо — това само по себе си е улика (вижте секцията за паметта на B42 по-долу).

Файлът debug.log на сървъра

Project Zomboid записва подробен лог в debug.log в директорията с данни на сървъра. Този файл често съдържа пълен Java stack trace, който сочи директно към причината за срива.

1. В GPanel отидете в раздела File Manager.
2. Навигирайте до /.cache/Logs/. Ще видите файлове, наречени напр. debug.log, DebugLog-server.txt или датирани лог файлове.
3. Отворете най-новия лог файл. Използвайте Ctrl+End или превъртете до самото дъно и четете нагоре оттам.
4. Потърсете ключовите думи OutOfMemoryError, IOException, NullPointerException или SandboxVars. Копирайте съответните редове — ще ви трябват, ако отворите билет за поддръжка.

Поправка 1 — Високо използване на памет при стартиране на Build 42 (Известен бъг в играта)

Ако сървърът ви излиза веднага при стартиране без грешка в конзолата или конзолата показва OutOfMemoryError или Java heap space грешка, сървърът свършва паметта си преди светът да завърши зареждането.

Симптоми

• Сървърът се стартира, конзолата превърта няколко секунди, след което спира без видима за играча грешка.
• Конзолата показва java.lang.OutOfMemoryError: Java heap space или GC overhead limit exceeded.
• Сървърът работи при някои рестартирания, но не при други (наличната памет варира).
• Сървърът е работил добре на B41, но се срива постоянно след надграждане до B42.

Стъпки

1. В GPanel кликнете върху сървъра си и отидете в раздела Console. Отбележете текущото разпределение на RAM на сървъра, показано в лентата за ресурси или информационния панел на сървъра.
2. Ако вашият план включва по-малко от 10 GB RAM, сървърът може да се срине по време на стартиране, тъй като B42 изисква приблизително 9 GB за инициализация. Ще трябва да надградите плана си или да изчакате The Indie Stone да издаде поправка.
3. Ако планът ви вече има 10 GB или повече и сървърът все още се срива при стартиране, отидете в раздела Startup в GPanel.
4. Потърсете поле, наречено Java Memory, Max RAM или Xmx. Уверете се, че е зададено на не повече от 80–85% от общата налична RAM. Например при план с 12 GB задайте това на 10240 (10 GB в мегабайти). Не задавайте равно или над общата RAM — операционната система и други процеси също се нуждаят от памет.
5. Кликнете Save в раздела Startup, след това рестартирайте сървъра.
6. Наблюдавайте конзолата по време на стартиране. Ако сървърът достигне реда SERVER STARTED или LuaManager: Loading lua files... завърши без срив, разпределението на паметта вече е достатъчно.

Поправка 2 — BackupsOnStart препълва /tmp (Срив при стартиране)

Project Zomboid може да бъде конфигуриран да създава пълно резервно копие на света всеки път, когато сървърът се стартира. Когато това резервно копие се записва в /tmp — който е ограничен по размер на повечето Linux хостове — сървърът се срива по средата на стартиране с грешка при запис на диска, когато /tmp се запълни.

Симптоми

• Сървърът се срива надеждно при всяко рестартиране, но е работил преди това.
• Конзолата или debug.log съдържа грешки като IOException: No space left on device или споменава запис в /tmp/.
• Сривовете обикновено стават по-лоши с течение на времето, когато запазеното състояние на света става все по-голямо.
• Сървърът понякога се стартира, ако опитате скоро след чисто рестартиране на хост възела (преди /tmp да се запълни отново).

Стъпки — Деактивирайте BackupsOnStart

1. В GPanel отидете в раздела File Manager.
2. Навигирайте до /.cache/server/. Потърсете файла за конфигурация на сървъра — обикновено се нарича servertest.ini или както е името на вашия сървър, последвано от .ini (напр. MyServer.ini).
3. Отворете файла .ini за редактиране.
4. Използвайте функцията за намиране на браузъра (Ctrl+F), за да търсите BackupsOnStart.
5. Променете стойността от true на false:

   BackupsOnStart=false

6. Докато сте във файла, проверете и настройката BackupsOnVersionChange и я задайте на false, ако дисковото пространство е проблем:

   BackupsOnVersionChange=false

7. Запазете файла и рестартирайте сървъра. Наблюдавайте конзолата, за да потвърдите, че сървърът достига реда SERVER STARTED.

Поправка 3 — Повреден SandboxVars.lua или конфигурация на сървъра

Project Zomboid съхранява настройките на света в Lua файл, наречен SandboxVars.lua. Ако този файл бъде редактиран ръчно и запазен със синтактична грешка или ако файловият трансфер е бил прекъснат, сървърът ще се срине веднага при стартиране, когато се опита да парсне файла.

Симптоми

• Конзолата показва ERROR: SandboxVars, LuaManager error или Lua parse грешка с номер на ред.
• Сривът започна да се случва веднага след като сте редактирали настройки във файла .ini или директно в SandboxVars.lua.
• Сървърът може да показва Bad argument #1 to или подобни Lua runtime грешки.

Стъпки — Проверка и поправка на SandboxVars.lua

1. В GPanel отидете в File Manager и навигирайте до /.cache/saves/multiplayer/<YourServerName>/.
2. Отворете SandboxVars.lua за редактиране.
3. Проверете дали файлът започва с VERSION = 1, (или подобно) вътре в блок SandboxVars = { и завършва със затваряща }. Всяка липсваща запетая, незатворена скоба или излишен символ ще доведе до неуспех при парсинг.
4. Ако не можете да идентифицирате грешката, най-безопасната поправка е да изтриете SandboxVars.lua изцяло. Сървърът ще го регенерира със стойности по подразбиране при следващото стартиране. Забележка: това нулира настройките на sandbox-а ви (лут, брой зомбита и т.н.) до стойностите по подразбиране — данните на картата и данните на играчите не са засегнати.
5. Проверете и файла .ini в /.cache/server/ за подобни проблеми, ако наскоро сте го редактирали ръчно. Уверете се, че всеки ред следва формата Key=Value без празни редове в стойност.
6. Запазете промените и рестартирайте сървъра.

Поправка 4 — Празна админ парола, причиняваща срив

Project Zomboid изисква непразна админ парола, за да стартира мултиплейър сървър. Ако полето за парола е празно, процесът на сървъра излиза веднага след опита за инициализиране на админ акаунта.

Симптоми

• Чисто нов сървър или наскоро нулиран сървър се проваля при всеки опит за стартиране.
• Изходът на конзолата е много кратък — сървърът отпечатва няколко реда за инициализация и след това спира.
• debug.log може да съдържа препратка към админ акаунта или валидирането на парола.

Стъпки

1. В GPanel кликнете върху сървъра си и отидете в раздела Startup.
2. Потърсете поле, наречено Admin Password или RCON Password. Уверете се, че съдържа стойност — не трябва да е празно.
3. Ако полето е празно, въведете парола. Използвайте поне 8 символа. Избягвайте специални символи като !, #, $ или @ в админ паролата, тъй като някои PZ версии не успяват да ги парсват правилно в startup аргументите.
4. Кликнете Save и рестартирайте сървъра.
5. Като вторична проверка отворете файла .ini в /.cache/server/ и потвърдете, че редът AdminPassword= има стойност след знака за равенство.

Поправка 5 — Нулиране на света (Последна мярка за постоянни сривове)

Ако запазен свят се повреди — например след тежък срив на сървъра, неуспешна актуализация или грешки на файловата система — самите данни на запазването може да са невъзстановими. В този случай изтриването на света и започването на нов е единствената опция.

Стъпки

1. Спрете сървъра си в GPanel преди да правите промени във файловете за запазване. Редактирането на файлове на работещ сървър може да причини допълнителна повреда.
2. В GPanel отидете в раздела File Manager.
3. Навигирайте до /.cache/saves/multiplayer/.
4. Ще видите една или повече папки с името на сървъра ви (напр. servertest). Преди изтриване, по желание изтеглете папката като резервно копие, като я изберете и използвате опцията за изтегляне — дори повредено запазване може да бъде частично възстановимо по-късно.
5. Изтрийте папката, съответстваща на името на сървъра ви в Multiplayer/. Не изтривайте самата папка Multiplayer.
6. Навигирайте също до /.cache/db/ и изтрийте файла <YourServerName>.db. Тази база данни съдържа статистика на играчите и може да препраща към стария свят — регенерирането й избягва несъответствия.
7. Стартирайте сървъра си. Той ще генерира нов свят, използвайки настройките във вашия .ini файл.

Бърза диагностична справка

Все още има сривове след всички стъпки?