Paper no responde: qué guardar ante un aviso del watchdog
Si Paper deja de responder y aparece un aviso del watchdog, conserva el registro completo del incidente, comprueba si el proceso sigue vivo y prepara una reproducción controlada antes de cambiar los tiempos de espera. El objetivo inmediato es recuperar una situación operativa conocida y conservar información suficiente para investigar. Que el servidor arranque después de reiniciarlo no demuestra que el problema esté resuelto.
Esta guía está dirigida a responsables de comunidades y equipos que necesitan entregar una incidencia a su operador o desarrollador. Se centra en Paper y en bloqueos prolongados. El procedimiento y el ejemplo son propuestas de trabajo; no describen pruebas ejecutadas por Mineando ni se deben trasladar automáticamente a Folia o a un servidor con mods.
Distingue el aviso del cierre
Paper explica que un aviso del watchdog puede señalar un tick bloqueado durante demasiado tiempo sin que el proceso haya terminado. El volcado de hilos muestra dónde estaba ejecutándose el hilo en ese instante; puede orientar la investigación, pero no siempre revela la causa. Consulta su guía de diagnóstico.
Anota por separado tres hechos: lo que vieron los jugadores, lo que escribió el servidor y lo que hizo el gestor del proceso. Si solo conservas una captura de la última línea, pierdes la secuencia necesaria para distinguirlos.
| Situación observada | Primera comprobación propuesta |
|---|---|
| Hay avisos, pero el proceso continúa | Registrar si vuelve a responder y cuándo, sin declararlo recuperado solo por seguir vivo |
| El proceso termina tras los avisos | Conservar el final del registro y comprobar qué componente ordenó el cierre o reinicio |
| El proceso desaparece sin avisos previos | Pedir al operador los eventos del host y del gestor del proceso; dejar la causa pendiente |
No atribuyas todas las desconexiones al watchdog. Vincula cada observación con una hora y una fuente verificable.
Guarda un expediente antes de acumular cambios
Nombra a una persona para coordinar la incidencia y registrar las intervenciones. Si el servicio sigue bloqueado, aplica el procedimiento de parada o recuperación acordado con el operador; no prolongues indefinidamente la interrupción para conseguir una captura perfecta.
Conserva estos elementos en una carpeta con fecha y un identificador de incidencia:
- El registro del arranque afectado, los avisos completos y las líneas anteriores y posteriores. Incluye los registros rotados que correspondan.
- La hora con zona horaria, duración observada y acciones de los jugadores inmediatamente anteriores.
- Versiones exactas de Minecraft, Paper, Java y plugins, además del último cambio conocido.
- Configuración relevante del watchdog y del mecanismo de reinicio, sin contraseñas ni claves.
- Eventos del host y métricas disponibles para ese intervalo: memoria, CPU, almacenamiento y dependencias externas.
- Intervenciones realizadas, con su hora y resultado; marca expresamente lo que no se pudo obtener.
Guarda un original con acceso restringido y prepara una copia revisada para compartir. Conserva las trazas útiles al retirar datos sensibles. No envíes la carpeta completa del servidor ni credenciales de bases de datos para demostrar un bloqueo.
Si planteáis restaurar, identifica antes el punto de recuperación y el progreso que se perdería. El ensayo de restauración sirve para preparar esa decisión; restaurar una copia no equivale a encontrar la causa.
No conviertas el silencio en un criterio de éxito
En la configuración global de Paper, watchdog.early-warning-delay determina cuándo empiezan los volcados y early-warning-every su intervalo, ambos en milisegundos. La referencia muestra 10000 y 5000 como valores predeterminados. Comprueba los valores reales de vuestra instalación.
La referencia de spigot.yml documenta settings.timeout-time en segundos y las opciones restart-on-crash y restart-script. El reinicio configurado ahí no cubre una terminación externa por el sistema operativo. Identifica también quién gestiona el proceso en vuestra infraestructura.
Estos controles tienen funciones distintas. Antes de tocarlos, registra el estado original y qué comportamiento quieres cambiar. Aumentar un umbral no constituye una prueba de que la operación que bloquea el servidor haya mejorado.
Paper también documenta disable.watchdog como una propiedad que desactiva el sistema de avisos en su referencia de propiedades del sistema. No la uses para aceptar una reparación solo porque desaparezcan los mensajes. Si un especialista necesita una configuración distinta durante una investigación, acotad el ensayo y dejad documentada la configuración final.
Usa la traza para formular una hipótesis comprobable
Pide al revisor que identifique el hilo y la operación que merece investigarse, y que explique qué información falta. El nombre de un plugin dentro de una traza no basta para decidir que hay que retirarlo. Relaciona esa pista con el momento del incidente, las dependencias implicadas y una acción reproducible.
Ejemplo hipotético: a las 19:42 una persona abre un menú de recompensas; después aparecen avisos y el juego deja de avanzar. La traza contiene llamadas relacionadas con esa función. La hipótesis de trabajo es que esa acción participa en el bloqueo. No permite afirmar todavía si falla el plugin, una dependencia o el entorno.
En una copia aislada, reproduce la misma acción con las mismas versiones y un estado representativo. Evita que la copia escriba en bases de datos o integraciones de producción. Pide al desarrollador que proponga una única variación y repite el escenario. Registra tanto las ejecuciones con bloqueo como las que no lo presentan; un intento sin fallo no descarta una incidencia intermitente.
Si se necesita un perfil adicional, acuerda la captura antes de reproducir. La documentación de profiling de Paper indica que el problema debe estar ocurriendo para que la captura sea útil. Un perfil posterior de una sesión tranquila no explica por sí solo el bloqueo anterior.
Define qué permite reabrir y qué sigue pendiente
Antes de repetir la prueba, acuerda el escenario, las repeticiones previstas, los resultados esperados y quién tomará la decisión. Separa «hemos recuperado el servicio» de «hemos confirmado la causa»: pueden ocurrir en momentos distintos.
Para aceptar una corrección, solicita el registro del escenario original, el cambio aplicado y el resultado al repetirlo. Comprueba además las funciones afectadas: por ejemplo, que la recompensa se entregue una sola vez y que su estado persista tras un reinicio limpio. Estos son criterios propuestos para el ejemplo, no garantías universales de estabilidad.
Si la solución exige actualizar componentes, utiliza una decisión de reapertura y recuperación con una versión identificada y una vía de vuelta preparada. Mantén la causa como pendiente si solo se ha aplicado una mitigación.
Para encargar una revisión de infraestructura Minecraft gestionada, aporta el expediente, el impacto sobre la comunidad y la ventana disponible para ensayar. Mineando trabaja con proyectos de pago y alcance individual. La monitorización, el mantenimiento y la cobertura de incidencias se acuerdan expresamente; una revisión no implica atención permanente.
