Serwery Project Zomboid mogą ulegać awariom lub nie uruchamiać się z kilku dobrze znanych powodów. Ten przewodnik obejmuje najczęstsze przyczyny obserwowane w zgłoszeniach do pomocy technicznej Legion Hosting — od błędu pamięci w Build 42, który wymaga dodatkowej pamięci RAM przy uruchamianiu, przez przepełnienie kopii zapasowych zapełniające /tmp, po uszkodzone pliki konfiguracyjne. Przejdź przez poniższe sekcje po kolei.

Zanim zaczniesz — zlokalizuj swoje logi awarii

Niemal każda awaria Project Zomboid pozostawia ślady w jednym z dwóch miejsc. Sprawdź oba przed podjęciem jakiejkolwiek naprawy, aby wiedzieć, która sekcja tego przewodnika dotyczy Twojego przypadku.

Dane wyjściowe konsoli GPanel

1. Zaloguj się do GPanel.
2. Wybierz swój serwer Project Zomboid z listy serwerów.
3. Kliknij zakładkę Console.
4. Przewiń do dołu danych wyjściowych. Szukaj linii oznaczonych ERROR, FATAL, OutOfMemoryError lub Exception. Ostatnie 20–30 linii przed zatrzymaniem serwera są zwykle najbardziej istotne.
5. Jeśli konsola jest pusta, proces serwera zakończył działanie, zanim zdołał cokolwiek zapisać — to samo w sobie jest wskazówką (zobacz sekcję o pamięci B42 poniżej).

Plik serwera debug.log

Project Zomboid zapisuje szczegółowy log do debug.log w katalogu danych serwera. Ten plik często zawiera pełny ślad stosu Java, który bezpośrednio wskazuje przyczynę awarii.

1. W GPanel przejdź do zakładki File Manager.
2. Przejdź do /.cache/Logs/. Zobaczysz pliki o nazwach takich jak debug.log, DebugLog-server.txt lub pliki logów z datą.
3. Otwórz najnowszy plik logu. Użyj Ctrl+End lub przewiń na sam dół i czytaj w górę od tego miejsca.
4. Szukaj słów kluczowych OutOfMemoryError, IOException, NullPointerException lub SandboxVars. Skopiuj odpowiednie linie — będą Ci potrzebne, jeśli otworzysz zgłoszenie do pomocy technicznej.

Naprawa 1 — Wysokie zużycie pamięci przy uruchamianiu w Build 42 (znany błąd gry)

Jeśli Twój serwer wychodzi natychmiast po uruchomieniu bez błędu w konsoli, lub konsola pokazuje OutOfMemoryError lub błąd przestrzeni sterty Java, serwerowi brakuje pamięci, zanim świat zakończy ładowanie.

Objawy

• Serwer się uruchamia, konsola przewija się przez kilka sekund, a następnie zatrzymuje się bez błędu widocznego dla gracza.
• Konsola pokazuje java.lang.OutOfMemoryError: Java heap space lub GC overhead limit exceeded.
• Serwer działa przy niektórych restartach, a przy innych nie (dostępność pamięci się różni).
• Serwer działał dobrze na B41, ale konsekwentnie ulega awarii po aktualizacji do B42.

Kroki

1. W GPanel kliknij swój serwer i przejdź do zakładki Console. Zanotuj aktualną alokację pamięci RAM serwera pokazaną na pasku zasobów lub w panelu informacji o serwerze.
2. Jeśli Twój plan obejmuje mniej niż 10 GB RAM, serwer może ulec awarii podczas uruchamiania, ponieważ B42 wymaga około 9 GB do inicjalizacji. Konieczne będzie ulepszenie planu lub poczekanie, aż Indie Stone wyda poprawkę.
3. Jeśli Twój plan ma już 10 GB lub więcej, a serwer nadal ulega awarii przy uruchamianiu, przejdź do zakładki Startup w GPanel.
4. Poszukaj pola oznaczonego Java Memory, Max RAM lub Xmx. Potwierdź, że jest ustawione na nie więcej niż 80–85% całkowitej dostępnej pamięci RAM. Na przykład w planie 12 GB ustaw tę wartość na 10240 (10 GB w megabajtach). Nie ustawiaj jej równej lub większej od całkowitej pamięci RAM — system operacyjny i inne procesy również potrzebują pamięci.
5. Kliknij Save w zakładce Startup, a następnie zrestartuj serwer.
6. Obserwuj konsolę podczas uruchamiania. Jeśli serwer osiągnie linię SERVER STARTED lub LuaManager: Loading lua files... zakończy się bez awarii, alokacja pamięci jest teraz wystarczająca.

Naprawa 2 — BackupsOnStart przepełniające /tmp (awaria przy uruchamianiu)

Project Zomboid można skonfigurować tak, aby tworzył pełną kopię zapasową świata za każdym razem, gdy serwer się uruchamia. Gdy ta kopia zapasowa jest zapisywana do /tmp — który ma ograniczony rozmiar na większości hostów Linux — serwer ulega awarii w trakcie uruchamiania z błędem zapisu na dysk, gdy /tmp się zapełni.

Objawy

• Serwer niezawodnie ulega awarii przy każdym restarcie, ale wcześniej działał.
• Konsola lub debug.log zawiera błędy takie jak IOException: No space left on device lub wzmianki o zapisie do /tmp/.
• Awarie mają tendencję do pogarszania się z czasem, w miarę jak zapis świata staje się większy.
• Serwer czasami uruchamia się, jeśli spróbujesz wkrótce po czystym ponownym uruchomieniu węzła hosta (zanim /tmp ponownie się zapełni).

Kroki — wyłączenie BackupsOnStart

1. W GPanel przejdź do zakładki File Manager.
2. Przejdź do /.cache/server/. Poszukaj pliku konfiguracyjnego serwera — zwykle nazywa się on servertest.ini lub jest nazwą Twojego serwera, po której następuje .ini (np. MyServer.ini).
3. Otwórz plik .ini do edycji.
4. Użyj funkcji wyszukiwania w przeglądarce (Ctrl+F), aby wyszukać BackupsOnStart.
5. Zmień wartość z true na false:

   BackupsOnStart=false

6. Będąc w pliku, sprawdź również ustawienie BackupsOnVersionChange i ustaw je na false, jeśli przestrzeń dyskowa jest problemem:

   BackupsOnVersionChange=false

7. Zapisz plik i zrestartuj serwer. Obserwuj konsolę, aby potwierdzić, że serwer osiąga linię SERVER STARTED.

Naprawa 3 — Uszkodzony plik SandboxVars.lua lub konfiguracji serwera

Project Zomboid przechowuje ustawienia świata w pliku Lua o nazwie SandboxVars.lua. Jeśli ten plik zostanie edytowany ręcznie i zapisany z błędem składni, lub jeśli transfer pliku został przerwany, serwer ulegnie awarii natychmiast przy uruchamianiu, gdy spróbuje przeanalizować plik.

Objawy

• Konsola pokazuje ERROR: SandboxVars, LuaManager error lub błąd parsowania Lua z numerem linii.
• Awaria zaczęła się zaraz po tym, jak edytowałeś ustawienia w pliku .ini lub bezpośrednio w SandboxVars.lua.
• Serwer może pokazywać Bad argument #1 to lub podobne błędy wykonania Lua.

Kroki — sprawdzenie i naprawa SandboxVars.lua

1. W GPanel przejdź do File Manager i przejdź do /.cache/saves/multiplayer/<YourServerName>/.
2. Otwórz SandboxVars.lua do edycji.
3. Sprawdź, czy plik zaczyna się od VERSION = 1, (lub podobnie) wewnątrz bloku SandboxVars = { i kończy się zamykającym }. Jakikolwiek brakujący przecinek, niezamknięty nawias klamrowy lub błędny znak spowoduje niepowodzenie parsowania.
4. Jeśli nie możesz zidentyfikować błędu, najbezpieczniejszą naprawą jest całkowite usunięcie SandboxVars.lua. Serwer wygeneruje go ponownie z domyślnymi wartościami przy następnym uruchomieniu. Uwaga: to resetuje Twoje ustawienia piaskownicy (łup, liczba zombie itp.) do wartości domyślnych — Twoje dane mapy i dane gracza nie są naruszone.
5. Sprawdź również plik .ini w /.cache/server/ pod kątem podobnych problemów, jeśli niedawno edytowałeś go ręcznie. Upewnij się, że każda linia ma format Key=Value bez pustych linii wewnątrz wartości.
6. Zapisz zmiany i zrestartuj serwer.

Naprawa 4 — Puste hasło administratora powodujące awarię

Project Zomboid wymaga niepustego hasła administratora do uruchomienia serwera wieloosobowego. Jeśli pole hasła jest puste, proces serwera wychodzi natychmiast po próbie zainicjowania konta administratora.

Objawy

• Zupełnie nowy serwer lub niedawno zresetowany serwer zawodzi przy każdej próbie uruchomienia.
• Dane wyjściowe konsoli są bardzo krótkie — serwer drukuje kilka linii inicjalizacji, a następnie zatrzymuje się.
• debug.log może zawierać odniesienie do konta administratora lub walidacji hasła.

Kroki

1. W GPanel kliknij swój serwer i przejdź do zakładki Startup.
2. Poszukaj pola oznaczonego Admin Password lub RCON Password. Potwierdź, że zawiera wartość — nie może być puste.
3. Jeśli pole jest puste, wprowadź hasło. Użyj co najmniej 8 znaków. Unikaj znaków specjalnych, takich jak !, #, $ lub @ w haśle administratora, ponieważ niektóre wersje PZ nie analizują ich poprawnie w argumentach uruchamiania.
4. Kliknij Save i zrestartuj serwer.
5. Jako dodatkowe sprawdzenie otwórz plik .ini w /.cache/server/ i potwierdź, że linia AdminPassword= ma wartość po znaku równości.

Naprawa 5 — Reset świata (ostateczność przy uporczywych awariach)

Jeśli zapis świata zostanie uszkodzony — na przykład po twardej awarii serwera, nieudanej aktualizacji lub błędach systemu plików — same dane zapisu mogą być nieodzyskiwalne. W takim przypadku usunięcie świata i rozpoczęcie od nowa jest jedyną opcją.

Kroki

1. Zatrzymaj swój serwer w GPanel przed wprowadzeniem jakichkolwiek zmian w plikach zapisu. Edytowanie plików na działającym serwerze może spowodować dalsze uszkodzenia.
2. W GPanel przejdź do zakładki File Manager.
3. Przejdź do /.cache/saves/multiplayer/.
4. Zobaczysz jeden lub więcej folderów z nazwą Twojego serwera (np. servertest). Przed usunięciem opcjonalnie pobierz folder jako kopię zapasową, zaznaczając go i używając opcji pobierania — nawet uszkodzony zapis może być częściowo odzyskiwalny później.
5. Usuń folder odpowiadający nazwie Twojego serwera wewnątrz Multiplayer/. Nie usuwaj samego folderu Multiplayer.
6. Przejdź również do /.cache/db/ i usuń plik <YourServerName>.db. Ta baza danych przechowuje statystyki graczy i może odwoływać się do starego świata — jej ponowne wygenerowanie pozwala uniknąć niezgodności.
7. Uruchom swój serwer. Wygeneruje on nowy świat, używając ustawień z Twojego pliku .ini.

Szybkie odniesienie diagnostyczne

Nadal awarie po wszystkich krokach?