Uma parada graciosa inesperada parece com alguém digitando /stop ou pressionando botão de desligamento, mas ninguém da equipe reconhece a ação. Paper pode registrar stack trace de origem quando a opção de debug está ativa. Painel também pode enviar parada para atualizar, aplicar política de idle ou encerrar tarefa.

Não trate encerramento limpo como prova de sabotagem ou defeito do Paper. Correlacione hora, processo e comando recebido; preserve logs antes do próximo restart, porque latest.log será substituído.

Confirme que foi shutdown gracioso

Procure mensagem final típica de parada e sequência de salvamento. Se console mostra crash, exception fatal ou saída abrupta, siga diagnóstico de crash em vez de investigação de comando. Se processo ainda vive mas painel mostra offline, confirme status real antes de iniciar outra instância.

Registre horário e compare com log do painel, agendador e sistema. Verifique se botão stop foi acionado, política de reinício automático executou ou host suspendeu instância vazia. Um deploy ou atualização pode substituir o processo sem pedido de operador humano.

Habilite debug para a próxima ocorrência

A documentação do Paper sugere habilitar debug em server.properties quando servidor para normalmente sem causa aparente. Faça backup do arquivo, pare o servidor antes de editar e reinicie. A próxima parada pode produzir stack trace associado ao evento.

Essa opção não identifica retrospectivamente um shutdown já concluído. Configure antes de reproduzir e monitore saída. Desligue verbosity adicional após investigação se volume de logs dificultar operação ou ocupar armazenamento.

Investigue quem pode executar stop

Revise membros com console e OP, plugins de painel Discord, bots, rotinas de restart e automações. Cada canal de administração deve ter operador identificado. Leia logs de comandos e mudanças de estado nas mesmas datas.

Se bot tem console remoto, confira se canal é somente leitura ou permite execução de comando. Se staff compartilha credencial, migre para contas individuais e reveja quem teve acesso. Não revogue tudo às cegas durante incidente, pois pode cortar acesso de recuperação.

Revise plugins e tarefas agendadas

Um plugin pode solicitar shutdown após concluir tarefa ou detectar condição própria. Examine stack trace com classe e método; nome de plugin pode guiar investigação, mas valide versão e configuração. Consulte documentação do autor e reproduza numa cópia antes de remover plugin de produção.

Veja também tarefa cron, watchdog externo, política de servidor vazio e deploy automático. Uma rotina pode iniciar stop gracioso antes de executar backup, migração ou update. Se horário se repete com precisão, correlacione com calendário.

Separe painel offline de processo encerrado

Alguns painéis avaliam log e porta para decidir estado visual. Listener pode falhar ou console pode desconectar sem shutdown real. Confirme PID ou atividade do serviço segundo ferramentas do host antes de usar iniciar novamente. Duas cópias gravando mundo são mais perigosas que esperar alguns minutos.

Em hosting sem acesso a sistema, peça ao suporte confirmação de encerramento, origem do sinal e ID da tarefa. Envie horários precisos e logs relevantes; não mande segredo de painel ou chave de forwarding.

Preserve evidência sem expor dados

Faça cópia do log completo e stack trace em local da equipe. Remova endereços e tokens antes de compartilhar com público. Documente se parada veio do painel, plugin, script ou hipótese ainda não confirmada.

Se desligamento pode estar ligado a incidente de acesso, revise senhas e roles conforme procedimento sem distribuir novas credenciais por chat aberto. Um restart depois da correção deve ser acompanhado até conclusão.

Teste hipótese com parada controlada

Em homologação, pause uma automação por vez e observe se evento reproduz. Se suspeita plugin, atualize ou remova apenas em cópia e compare. Defina janela maior que o ciclo agendado que pode disparar shutdown; algumas tarefas rodam diariamente.

Depois de correção, monitore vários ciclos e guarde causa confirmada e versão. Se nada aparece, colete próxima ocorrência com debug, em vez de desligar funções aleatórias até o sintoma sumir.

Siga a página do Paper sobre shutdown gracioso inesperado, confira opção debug na referência de server.properties e leia o mapa de logs e diretórios. A evidência deve mostrar o evento da próxima parada para identificar origem.

Correlacione stack trace com tarefas recentes

Um stack trace pode identificar plugin chamador, tarefa scheduler ou processo de shutdown, mas preserve as linhas antes e depois para não tirar contexto. Compare horários com backup, reinício de painel, deploy, update e rotina de servidor vazio. Tarefa periódica costuma produzir repetição previsível ao longo de vários dias.

Se debug aumenta quantidade de logs, faça cópia do arquivo logo após reproduzir e limite o período de coleta. Desative configuração extra quando a evidência não for mais necessária e mantenha a causa confirmada no registro interno.

Revise a origem no painel e no sistema

Se stack trace mostra fluxo que vem de plugin, teste versão compatível numa cópia e consulte o autor. Se não há origem Java, procure agendador ou provedor. Solicite o ID da ação de stop e horário exato; isso permite correlacionar processo sem expor console administrativo.

Investigue desligamento na janela correta

Registre se botão stop, console ou API foi usado por operador autorizado e preserve logs do proxy e Paper juntos. Se múltiplos backends encerram no mesmo horário, causa pode ser automação comum ou manutenção do host. Compare um serviço afetado e outro não afetado para restringir hipótese.

Revise shutdown logo após atualização

Se parada começou após atualizar plugin ou Paper, compare versões e mudanças de agendador com a última configuração estável. Reproduza numa cópia, alterando somente o componente suspeito. Não remova plugins dependentes da produção enquanto jogadores estão conectados para testar hipótese.

Feche a investigação com responsável

Depois de encontrar origem, remova acesso temporário ou corrija automação, registre quem alterou e monitore o próximo ciclo agendado. Se causa permaneceu incerta, mantenha coleta debug tempo suficiente para novo caso e planeje suporte com Paper ou provedor, sem deixar logs detalhados habilitados indefinidamente.

Valide o próximo ciclo antes de encerrar

Se causa era agendador, deixe novo evento ocorrer numa janela observada e confirme que Paper permanece ativo. Se a correção era de plugin, verifique chat, mundos e rotina que acionava parada. Guarde janela de log e resultado para distinguir correção duradoura de coincidência.

Fontes e referências

Documentação consultada em 2026-10-08. Os exemplos precisam ser conferidos na versão instalada; este guia não afirma que a configuração foi testada no seu ambiente.