Os servidores de Project Zomboid podem crashar ou falhar ao iniciar por várias razões bem conhecidas. Este guia abrange as causas mais comuns encontradas nos tickets de suporte da Legion Hosting — desde um bug de memória do Build 42 que requer RAM extra na inicialização, até um excesso de backups que enche o /tmp, até ficheiros de configuração corrompidos. Siga as secções abaixo por ordem.

Antes de Começar — Localize os Seus Logs de Crash

Quase todos os crashes do Project Zomboid deixam evidências num de dois locais. Verifique ambos antes de tentar qualquer correção, para saber qual secção deste guia se aplica ao seu caso.

Saída da Consola do GPanel

1. Inicie sessão no GPanel.
2. Selecione o seu servidor Project Zomboid na lista de servidores.
3. Clique no separador Console.
4. Desloque-se até ao final da saída. Procure linhas marcadas com ERROR, FATAL, OutOfMemoryError ou Exception. As últimas 20–30 linhas antes do servidor parar são geralmente as mais relevantes.
5. Se a consola estiver vazia, o processo do servidor terminou antes de conseguir escrever algo — isto é por si só uma pista (consulte a secção de memória do B42 abaixo).

O Ficheiro debug.log do Servidor

O Project Zomboid escreve um log detalhado em debug.log no diretório de dados do servidor. Este ficheiro contém frequentemente um stack trace Java completo que aponta diretamente para a causa do crash.

1. No GPanel, vá ao separador File Manager.
2. Navegue até /.cache/Logs/. Verá ficheiros com nomes como debug.log, DebugLog-server.txt ou ficheiros de log com data.
3. Abra o ficheiro de log mais recente. Use Ctrl+End ou desloque-se até ao final e leia de baixo para cima.
4. Procure as palavras-chave OutOfMemoryError, IOException, NullPointerException ou SandboxVars. Copie as linhas relevantes — vai precisar delas se abrir um ticket de suporte.

Correção 1 — Uso Elevado de Memória do Build 42 na Inicialização (Bug Conhecido do Jogo)

Se o seu servidor encerra imediatamente na inicialização sem erro na consola, ou a consola mostra OutOfMemoryError ou um erro de espaço de heap Java, o servidor está a ficar sem memória antes do mundo terminar de carregar.

Sintomas

• O servidor inicia, a consola desloca-se durante alguns segundos e depois para sem erro visível para os jogadores.
• A consola mostra java.lang.OutOfMemoryError: Java heap space ou GC overhead limit exceeded.
• O servidor funciona em alguns reinícios mas não noutros (a disponibilidade de memória varia).
• O servidor funcionava bem no B41 mas crasha consistentemente após atualizar para o B42.

Passos

1. No GPanel, clique no seu servidor e vá ao separador Console. Note a alocação de RAM atual do seu servidor mostrada na barra de recursos ou no painel de informações do servidor.
2. Se o seu plano inclui menos de 10 GB de RAM, o servidor pode crashar durante a inicialização porque o B42 requer aproximadamente 9 GB para inicializar. Terá de fazer upgrade do seu plano ou aguardar que a Indie Stone lance uma correção.
3. Se o seu plano já tem 10 GB ou mais e o servidor continua a crashar na inicialização, vá ao separador Startup no GPanel.
4. Procure um campo chamado Java Memory, Max RAM ou Xmx. Confirme que está definido para não mais que 80–85% da sua RAM total disponível. Por exemplo, num plano de 12 GB, defina isto para 10240 (10 GB em megabytes). Não o defina igual ou acima da sua RAM total — o sistema operativo e outros processos também precisam de memória.
5. Clique em Save no separador Startup e depois reinicie o seu servidor.
6. Observe a consola durante a inicialização. Se o servidor atingir a linha SERVER STARTED ou LuaManager: Loading lua files... completar sem crashar, a alocação de memória é agora suficiente.

Correção 2 — BackupsOnStart a Transbordar o /tmp (Crash na Inicialização)

O Project Zomboid pode ser configurado para criar um backup completo do mundo sempre que o servidor inicia. Quando este backup é escrito em /tmp — que tem tamanho limitado na maioria dos hosts Linux — o servidor crasha a meio da inicialização com um erro de escrita em disco assim que o /tmp fica cheio.

Sintomas

• O servidor crasha de forma fiável em cada reinício, mas funcionava anteriormente.
• A consola ou o debug.log contém erros como IOException: No space left on device ou menções de escrita em /tmp/.
• Os crashes tendem a piorar ao longo do tempo à medida que o ficheiro de salvamento do mundo cresce.
• O servidor por vezes inicia se tentar pouco depois de um reinício limpo do nó do host (antes do /tmp encher novamente).

Passos — Desativar BackupsOnStart

1. No GPanel, vá ao separador File Manager.
2. Navegue até /.cache/server/. Procure o seu ficheiro de configuração do servidor — tipicamente chama-se servertest.ini ou o nome do seu servidor seguido de .ini (ex.: MyServer.ini).
3. Abra o ficheiro .ini para edição.
4. Use a função de pesquisa do seu navegador (Ctrl+F) para procurar BackupsOnStart.
5. Altere o valor de true para false:

   BackupsOnStart=false

6. Enquanto estiver no ficheiro, verifique também a definição BackupsOnVersionChange e defina-a como false se o espaço em disco for uma preocupação:

   BackupsOnVersionChange=false

7. Guarde o ficheiro e reinicie o seu servidor. Monitorize a consola para confirmar que o servidor atinge a linha SERVER STARTED.

Correção 3 — SandboxVars.lua ou Configuração do Servidor Corrompida

O Project Zomboid armazena as definições do mundo num ficheiro Lua chamado SandboxVars.lua. Se este ficheiro for editado manualmente e guardado com um erro de sintaxe, ou se uma transferência de ficheiro foi interrompida, o servidor crashará imediatamente na inicialização quando tentar analisar o ficheiro.

Sintomas

• A consola mostra ERROR: SandboxVars, LuaManager error ou um erro de análise Lua com um número de linha.
• O crash começou a acontecer logo após ter editado as definições no ficheiro .ini ou no SandboxVars.lua diretamente.
• O servidor pode mostrar Bad argument #1 to ou erros de runtime Lua semelhantes.

Passos — Verificar e Reparar o SandboxVars.lua

1. No GPanel, vá ao File Manager e navegue até /.cache/saves/multiplayer/<YourServerName>/.
2. Abra o SandboxVars.lua para edição.
3. Verifique que o ficheiro começa com VERSION = 1, (ou similar) dentro de um bloco SandboxVars = {, e termina com um } de fecho. Qualquer vírgula em falta, chaveta não fechada ou caractere perdido causará uma falha de análise.
4. Se não conseguir identificar o erro, a correção mais segura é eliminar o SandboxVars.lua completamente. O servidor irá regenerá-lo com valores predefinidos na próxima inicialização. Nota: isto repõe as suas definições de sandbox (loot, contagem de zombies, etc.) para os valores predefinidos — os seus dados de mapa e dados de jogadores não são afetados.
5. Verifique também o ficheiro .ini em /.cache/server/ para problemas semelhantes se o editou recentemente à mão. Certifique-se de que cada linha segue o formato Key=Value sem linhas em branco dentro de um valor.
6. Guarde as alterações e reinicie o servidor.

Correção 4 — Palavra-passe de Administrador Vazia a Causar Crash

O Project Zomboid requer uma palavra-passe de administrador não vazia para iniciar um servidor multijogador. Se o campo da palavra-passe estiver em branco, o processo do servidor encerra imediatamente após tentar inicializar a conta de administrador.

Sintomas

• Servidor novo ou servidor recentemente reposto falha em todas as tentativas de início.
• A saída da consola é muito curta — o servidor imprime algumas linhas de inicialização e depois para.
• O debug.log pode conter uma referência à conta de administrador ou validação de palavra-passe.

Passos

1. No GPanel, clique no seu servidor e vá ao separador Startup.
2. Procure um campo chamado Admin Password ou RCON Password. Confirme que contém um valor — não pode estar em branco.
3. Se o campo estiver vazio, introduza uma palavra-passe. Use pelo menos 8 caracteres. Evite caracteres especiais como !, #, $ ou @ na palavra-passe de administrador, pois algumas versões do PZ falham ao analisá-los corretamente nos argumentos de inicialização.
4. Clique em Save e reinicie o servidor.
5. Como verificação secundária, abra o ficheiro .ini em /.cache/server/ e confirme que a linha AdminPassword= tem um valor após o sinal de igual.

Correção 5 — Repor o Mundo (Último Recurso para Crashes Persistentes)

Se um ficheiro de salvamento do mundo se tornar corrompido — por exemplo, após um crash do servidor, uma atualização falhada ou erros do sistema de ficheiros — os dados de salvamento podem ser irrecuperáveis. Neste caso, eliminar o mundo e começar de novo é a única opção.

Passos

1. Pare o seu servidor no GPanel antes de fazer quaisquer alterações aos ficheiros de salvamento. Editar ficheiros num servidor em execução pode causar mais corrupção.
2. No GPanel, vá ao separador File Manager.
3. Navegue até /.cache/saves/multiplayer/.
4. Verá uma ou mais pastas com o nome do seu servidor (ex.: servertest). Antes de eliminar, opcionalmente descarregue a pasta como backup selecionando-a e usando a opção de download — mesmo um salvamento corrompido pode ser parcialmente recuperável mais tarde.
5. Elimine a pasta correspondente ao nome do seu servidor dentro de Multiplayer/. Não elimine a pasta Multiplayer em si.
6. Navegue também até /.cache/db/ e elimine o ficheiro <YourServerName>.db. Esta base de dados contém estatísticas de jogadores e pode referenciar o mundo antigo — regenerá-la evita inconsistências.
7. Inicie o seu servidor. Ele irá gerar um mundo novo usando as definições no seu ficheiro .ini.

Referência Rápida de Diagnóstico

Continua a Crashar Após Todos os Passos?