Saltar al contenido principal

Reinicios inesperados

Un servidor que se cae o se reinicia solo es uno de los problemas más frustrantes. Esta guía te ayuda a identificar la causa y solucionarla.

Paso 1 — Leer los logs​

El primer paso siempre es leer los logs. En SkyPanel:

  1. Ve a Console y mira los últimos mensajes antes del reinicio
  2. O abre Files → logs → latest.log
  3. Busca al final del archivo — el error que causó el cierre estará justo antes del mensaje de apagado

Palabras clave a buscar:

ERROR
FATAL
Exception
OutOfMemoryError
Killed
Watchdog

Paso 2 — Revisar el crash report​

Si el servidor generó un crash report, lo encontrarás en:

crash-reports/crash-YYYY-MM-DD_HH.MM.SS-server.txt

El crash report tiene esta estructura:

---- Minecraft Crash Report ----
Time: 2024-01-15 14:30:00
Description: Exception in server tick loop

java.lang.NullPointerException: ...
    at com.pluginX.ClaseY.metodoZ(ClaseY.java:45)
    at ...
    
-- System Details --
Minecraft Version: 1.21.1
Java Version: 21.0.1, ...
Memory: 2GB / 6GB

La línea más importante es la que describe la excepción (java.lang.NullPointerException, OutOfMemoryError, etc.) y el stack trace que la sigue.

Causa: OutOfMemoryError​

Síntoma en logs​

java.lang.OutOfMemoryError: Java heap space

o

java.lang.OutOfMemoryError: GC overhead limit exceeded

Qué significa​

El servidor se quedó sin memoria RAM asignada. La JVM no pudo continuar y mató el proceso.

Soluciones​

1. Aumentar la RAM asignada

En SkyPanel → Startup, aumenta el valor de -Xmx. Si tu plan tiene 8 GB, prueba con -Xms6G -Xmx6G.

2. Buscar fugas de memoria (memory leaks)

Si el servidor funciona bien durante horas y luego cae, probablemente hay un plugin con una fuga de memoria. Para identificarlo:

  1. Instala el plugin Spark si no lo tienes

  2. Ejecuta periódicamente /spark heapsummary

  3. Spark mostrará qué clases están acumulando más memoria — busca las que crecen sin parar

  4. Desactiva plugins uno por uno hasta que el servidor deje de caer. El último que desactivaste es el culpable.

3. Revisar la configuración de JVM

Asegúrate de que -Xms es igual a -Xmx. Si -Xms es mucho menor, la JVM puede tener problemas al expandir el heap y causar GC overhead.

Consulta la guía de Flags de Aikar para la configuración óptima.

Causa: Watchdog Thread Crash​

Síntoma en logs​

[WARN] A single server tick took 60.00 seconds (should be max 0.05)
[FATAL] The server has stopped responding! This is a crash report.

Qué significa​

El servidor estuvo demasiado tiempo sin poder procesar un tick (por lag severo o un bucle infinito en un plugin). El Watchdog de Paper/Spigot detecta esto y mata el proceso para evitar que quede "colgado" de forma indefinida.

Soluciones​

1. Identificar el cuello de botella

Instala Spark y ejecuta un perfil justo antes o durante el lag:

/spark profiler start

Espera a que el servidor se congele y (si puedes) para el profiler:

/spark profiler stop

El informe mostrará qué método o plugin está bloqueando el tick principal.

2. Causas comunes de Watchdog

CausaIndicación en logsSolución
Plugin con bucle infinitoMismo método repetido en el stack traceActualizar o desinstalar el plugin
Demasiadas entidadesEntity Tick al tope del profilerReducir mobs, usar ClearLag
I/O de disco lentoChunkSave o ChunkLoad al topePregenerar mapa, verificar almacenamiento
Redstone masivaBlockTick al topeRevisar granjas de redstone
Operación de base de datos síncronaLlamadas MySQL en el tick principalActualizar el plugin a versión async

3. Aumentar el umbral del Watchdog (solución temporal)

En paper-global.yml:

# Tiempo en segundos antes de que Watchdog mate el servidor
# Default: 60. Aumentar da más margen pero puede dejar el servidor colgado más tiempo.
watchdog:
  early-warning-every: 5000
  early-warning-delay: 10000
aviso

Aumentar el timeout del Watchdog no soluciona el problema de raíz — solo retrasa el crash. Úsalo solo como medida temporal mientras investigas.

Causa: Plugin causando un crash​

Síntoma en logs​

[SEVERE] Could not pass event ... to PluginX v1.2.3
java.lang.NullPointerException
    at com.pluginx.ClaseX.metodo(ClaseX.java:123)

o el servidor se cierra sin mensaje con el nombre del plugin en el stack trace.

Cómo identificar el plugin problemático​

Método rápido: mira el stack trace en el crash report. El nombre del paquete suele indicar el plugin (ej: com.sk89q.worldedit → WorldEdit, me.clip.placeholderapi → PlaceholderAPI).

Método sistemático:

  1. Para el servidor
  2. Ve a Files → plugins
  3. Renombra el .jar de un plugin a .jar.disabled (empieza por los más recientes o sospechosos)
  4. Arranca el servidor
  5. Si no cae, ese plugin era el problema
  6. Repite con el siguiente si el servidor sigue cayendo

Soluciones​

  • Actualizar el plugin: muchos crashes se solucionan con la última versión
  • Desinstalar el plugin: si no hay actualización o el plugin está abandonado
  • Reportar al autor: si el bug es reproducible, el autor del plugin puede arreglarlo
  • Buscar un fork o alternativa: si el plugin no tiene mantenimiento activo

Causa: Script de reinicio automático​

Síntoma​

El servidor "se reinicia" regularmente sin error aparente.

Qué significa​

Pterodactyl / SkyPanel puede estar configurado para reiniciar el servidor si detecta que no responde o si el proceso termina. Esto se combina con los Schedules de SkyPanel.

Verificar​

  1. Ve a Schedules en tu servidor — comprueba si hay algún schedule configurado con un reinicio (restart)
  2. Ve a Settings — verifica la configuración de "Crash Detection" si está disponible

Si el servidor se reinicia sin error en los logs, probablemente el proceso de Java terminó limpiamente (por una llamada a /stop del Watchdog o un Schedule) y SkyPanel lo reinició automáticamente.

Causa: OOM del sistema operativo (OOM Killer)​

Síntoma​

El servidor desaparece sin ningún mensaje de error en los logs. El log se corta abruptamente.

Qué significa​

El kernel de Linux mató el proceso de Java porque el sistema se quedó sin memoria RAM (no el heap de Java, sino la RAM total del nodo). Esto es más raro en MixelNodes porque los recursos están aislados por contenedor, pero puede ocurrir.

Diagnóstico​

Si tienes acceso a los logs del nodo (contacta con soporte), busca:

kernel: Out of memory: Killed process XXXX (java)

Solución​

Contacta con el soporte de MixelNodes. Pueden:

  • Verificar si hay un problema en el nodo
  • Ajustar los límites de memoria del contenedor
  • Migrar tu servidor a un nodo con más recursos disponibles

Checklist de diagnóstico de reinicios​

Cuando el servidor cae, verifica en orden:

  • ¿Hay un archivo en crash-reports/? → Léelo
  • ¿El log muestra OutOfMemoryError? → Aumentar RAM o buscar memory leak
  • ¿El log muestra Watchdog? → Usar Spark para encontrar el cuello de botella
  • ¿El log muestra el nombre de un plugin en el error? → Actualizar o desinstalar ese plugin
  • ¿El log se corta sin error? → Contactar con soporte (posible OOM del sistema)
  • ¿El servidor se reinicia regularmente sin error? → Revisar Schedules en SkyPanel

Herramientas recomendadas​

HerramientaUsoEnlace
SparkProfiling y diagnóstico de rendimientospark.lucko.me
mclo.gsSubir logs para compartir con soportemclo.gs
timings.aikar.coAnálisis de timings de Papertimings.aikar.co

Contactar con soporte​

Si no puedes identificar la causa:

  1. Sube el log completo a mclo.gs
  2. Copia el crash report si existe
  3. Ve al Discord de MixelNodes y abre un ticket con:
    • El enlace de mclo.gs
    • El crash report
    • Qué plugins tienes instalados
    • Qué estaba pasando cuando cayó (muchos jugadores, alguien usó una granja, etc.)