Servidores de Project Zomboid podem crashar ou falhar ao iniciar por vários motivos bem conhecidos. Este guia cobre as causas mais comuns vistas nos tickets de suporte da Legion Hosting — desde um bug de memória da Build 42 que requer RAM extra na inicialização, até um estouro de backup que enche o /tmp, até arquivos de configuração corrompidos. Siga as seções abaixo em ordem.

Antes de Começar — Localize Seus Logs de Crash

Quase todo crash de Project Zomboid deixa evidências em um de dois lugares. Verifique ambos antes de tentar qualquer correção, para saber qual seção deste guia se aplica ao seu caso.

Saída do Console do GPanel

1. Faça login no GPanel.
2. Selecione seu servidor Project Zomboid na lista de servidores.
3. Clique na aba Console.
4. Role até o final da saída. Procure por 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 o console estiver vazio, o processo do servidor encerrou antes de conseguir escrever qualquer coisa — isso por si só é uma pista (veja a seção de memória da B42 abaixo).

O Arquivo debug.log do Servidor

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

1. No GPanel, vá para a aba File Manager.
2. Navegue até /.cache/Logs/. Você verá arquivos nomeados como debug.log, DebugLog-server.txt ou arquivos de log datados.
3. Abra o arquivo de log mais recente. Use Ctrl+End ou role até o final e leia de baixo para cima.
4. Procure pelas palavras-chave OutOfMemoryError, IOException, NullPointerException ou SandboxVars. Copie as linhas relevantes — você precisará delas caso abra um ticket de suporte.

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

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

Sintomas

• O servidor inicia, o console rola por alguns segundos, depois para sem erro visível para o jogador.
• O console mostra java.lang.OutOfMemoryError: Java heap space ou GC overhead limit exceeded.
• O servidor funciona em algumas reinicializações, mas não em outras (a disponibilidade de memória varia).
• O servidor funcionava bem na B41, mas crasha consistentemente após atualizar para a B42.

Passos

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

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

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

Sintomas

• O servidor crasha de forma confiável em toda reinicialização, mas estava funcionando anteriormente.
• O console ou debug.log contém erros como IOException: No space left on device ou menciona escrita em /tmp/.
• Os crashes tendem a piorar com o tempo conforme o save do mundo cresce.
• O servidor às vezes inicia se você tentar logo após um reboot limpo do nó host (antes do /tmp encher novamente).

Passos — Desabilitar BackupsOnStart

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

   BackupsOnStart=false

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

   BackupsOnVersionChange=false

7. Salve o arquivo e reinicie seu servidor. Monitore o console para confirmar que o servidor alcança a linha SERVER STARTED.

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

O Project Zomboid armazena as configurações do mundo em um arquivo Lua chamado SandboxVars.lua. Se este arquivo for editado manualmente e salvo com um erro de sintaxe, ou se uma transferência de arquivo foi interrompida, o servidor crashará imediatamente na inicialização ao tentar interpretar o arquivo.

Sintomas

• O console mostra ERROR: SandboxVars, LuaManager error ou um erro de parse Lua com número de linha.
• O crash começou a acontecer logo após você editar configurações no arquivo .ini ou no SandboxVars.lua diretamente.
• O servidor pode mostrar Bad argument #1 to ou erros de runtime Lua similares.

Passos — Verificar e Reparar o SandboxVars.lua

1. No GPanel, vá para File Manager e navegue até /.cache/saves/multiplayer/<YourServerName>/.
2. Abra SandboxVars.lua para edição.
3. Verifique se o arquivo começa com VERSION = 1, (ou similar) dentro de um bloco SandboxVars = {, e termina com uma chave de fechamento }. Qualquer vírgula faltando, chave não fechada ou caractere solto causará uma falha de parse.
4. Se você não conseguir identificar o erro, a correção mais segura é deletar o SandboxVars.lua inteiramente. O servidor irá regenerá-lo com valores padrão na próxima inicialização. Nota: isso reseta suas configurações de sandbox (loot, quantidade de zumbis, etc.) para os padrões — seus dados de mapa e dados de jogadores não são afetados.
5. Verifique também o arquivo .ini em /.cache/server/ para problemas similares, caso você o tenha editado manualmente recentemente. Certifique-se de que toda linha segue o formato Key=Value sem linhas em branco dentro de um valor.
6. Salve as alterações e reinicie o servidor.

Correção 4 — Senha de Admin Vazia Causando Crash

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

Sintomas

• Servidor novo ou servidor recentemente resetado falha em toda tentativa de inicialização.
• A saída do console é muito curta — o servidor imprime algumas linhas de inicialização e depois para.
• O debug.log pode conter uma referência à conta de admin ou validação de senha.

Passos

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

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

Se um save de mundo se tornar corrompido — por exemplo, após um crash forçado do servidor, uma atualização falha ou erros no sistema de arquivos — os dados do save podem ser irrecuperáveis. Neste caso, deletar o mundo e começar do zero é a única opção.

Passos

1. Pare seu servidor no GPanel antes de fazer qualquer alteração nos arquivos de save. Editar arquivos em um servidor em execução pode causar mais corrupção.
2. No GPanel, vá para a aba File Manager.
3. Navegue até /.cache/saves/multiplayer/.
4. Você verá uma ou mais pastas com o nome do seu servidor (ex.: servertest). Antes de deletar, opcionalmente baixe a pasta como backup selecionando-a e usando a opção de download — mesmo um save corrompido pode ser parcialmente recuperável depois.
5. Delete a pasta correspondente ao nome do seu servidor dentro de Multiplayer/. Não delete a pasta Multiplayer em si.
6. Também navegue até /.cache/db/ e delete o arquivo <YourServerName>.db. Este banco de dados contém estatísticas de jogadores e pode referenciar o mundo antigo — regenerá-lo evita inconsistências.
7. Inicie seu servidor. Ele gerará um mundo novo usando as configurações do seu arquivo .ini.

Referência Rápida de Diagnóstico

Ainda Crashando Após Todos os Passos?