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 простор, на серверот му снемува меморија пред светот да заврши со вчитување.

Симптоми

• Серверот се стартува, конзолата скролува неколку секунди, потоа запира без грешка видлива за играчот.
• Конзолата покажува 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 грешка при парсирање со број на линија.
• Паѓањето започна веднаш откако ги уредивте поставките во датотеката .ini или директно во SandboxVars.lua.
• Серверот може да покаже Bad argument #1 to или слични Lua грешки при извршување.

Чекори — проверете и поправете го 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 верзии не успеваат правилно да ги парсираат во аргументите за стартување.
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.

Брза дијагностичка референца

Сè уште паѓа по сите чекори?