Cómo un archivo de texto llena un disco en silencio
Con WP_DEBUG_LOG activado, cada notice, warning y deprecation de PHP se añade a
wp-content/debug.log. Sin rotación, sin tope, sin limpieza
- solo crece. En un sitio que nadie vigila, ese archivo sobrevive al problema para el que se activó.
Todo iba bien, y de pronto nada funciona. Las subidas fallan. Las actualizaciones fallan. A veces
el propio sitio se cae. Miras el disco: lleno. El archivo más grande con diferencia:
debug.log.
Un plugin que escribe un notice en cada petición añade miles de líneas casi idénticas al día. Meses después el log pesa gigabytes, los backups se hinchan con él, y la primera señal de que algo va mal es un disco lleno - que parece un problema de hosting, no de logging.
Por qué nunca se detiene solo
- El archivo es append-only: solo se le añade. Nada en WordPress lo rota, trunca o limita - nunca.
- El mismo notice se repite en cada petición. Una llamada a función deprecated en una página concurrida es una línea por visita.
- En la mayoría de sitios WP_DEBUG debería haber estado apagado en producción hace meses - el log se sigue llenando lo lea alguien o no.
- Y cuanto más grande se hace, menos lo abre nadie, así que los errores reales dentro también quedan sin leer.
Qué hace Debug Log Guard con él
Debug Log Guard encuentra el log que PHP realmente escribe - respeta las
constantes WP_DEBUG y cae al error_log de php.ini cuando ese es el
destino real - y luego te da tres cosas:
- Un resumen agrupado. El mismo mensaje colapsado en una fila con un contador, la fuente (core, plugin o tema) y la primera y última vez que se vio. La línea que llenó dos gigabytes queda arriba en lugar de repetirse a lo largo de cuatro millones de filas.
- Un tail en vivo. Las últimas 200 líneas, en streaming - nunca carga el archivo entero en memoria, así que un log de varios GB abre en segundos en lugar de colgar la página.
- Acciones seguras para encogerlo. Compact colapsa las repeticiones, Rotate archiva el archivo y empieza de nuevo, Clear lo vacía. Las tres hacen primero el backup y son atómicas - una escritura parcial nunca corrompe el log.
El guardia de tamaño cada hora
Un trabajo de WP-Cron revisa el log una vez por hora. Pasado tu umbral - 50 MB por defecto - ejecuta la acción que elegiste: compact, rotate o clear, guardando el número de backups que configuraste. Tú decides qué significa "demasiado grande"; el guardia lo hace cumplir mientras duermes.
También sabe cuándo no compactar: un log que ya pasa de ~1 GB se fuerza a rotar, porque colapsar un archivo de varios GB no es una operación in-place segura. La compactación primero comprueba el disco libre, escanea archivos gigantes desde el tail en lugar de desde arriba, y corre con presupuesto de tiempo - si se agota, aborta y deja el original intacto.
Corre sobre WP-Cron, así que entre ticks el archivo puede seguir creciendo - el guardia limita el daño, no detiene las escrituras.
El log es el síntoma - arregla la fuente
Reducir el archivo no arregla lo que escribe en él. El resumen agrupado es la parte que importa para eso: la columna de fuente nombra el plugin, el tema o el archivo del core que genera cada mensaje, para que arregles, reemplaces o reportes lo que espamea el log en lugar de borrar la evidencia.
Dos avisos más que merece la pena tener. El Guard marca cuando WP_DEBUG_DISPLAY se queda encendido en producción - eso imprime errores a tus visitantes - y avisa cuando el propio archivo de log es públicamente accesible, algo que la gente realmente busca. Si nadie lee el log en un sitio en vivo, el arreglo honesto es apagar WP_DEBUG; Config Manager escribe las constantes de wp-config con seguridad, con backup.
Debug Log Guard es un módulo Pro - un clic a una tabla agrupada con el culpable nombrado, y un guardia cron que mantiene el archivo limitado.
Pro desde $79/año →FAQ: debug.log demasiado grande
¿Por qué mi archivo debug.log es tan grande?
WP_DEBUG_LOG añade cada notice, warning y deprecation - y el mismo mensaje suele repetirse en cada petición. Un plugin escribiendo un notice por vista de página son miles de líneas al día. Nada en WordPress rota o limita el archivo, así que crece hasta que el disco se llena.
¿Es seguro borrar debug.log?
Sí - se regenera con el siguiente error. Pero pierdes la evidencia de qué plugin lo espamea, y si la causa sigue ahí se vuelve a llenar enseguida. El clear y rotate de Debug Log Guard corren backup-first, así que puedes encogerlo sin perder los datos.
¿Cómo detengo el crecimiento de debug.log?
Dos formas, y no son el mismo trabajo. El guardia de tamaño cada hora de Debug Log Guard limita el archivo a tu umbral - 50MB por defecto - con compact, rotate o clear. Detener las escrituras significa arreglar el plugin que las espamea o apagar WP_DEBUG; el resumen agrupado nombra la fuente en ambos casos.
¿Arregla Debug Log Guard los errores del log?
No - te muestra qué plugin, tema o archivo del core los escribe. La tabla agrupada da a cada mensaje un contador y una fuente, para que arregles o reemplaces al culpable en lugar de borrar repetidamente un log que se vuelve a llenar.
¿Y si necesito WP_DEBUG en un sitio en vivo?
Entonces el setup seguro es WP_DEBUG_LOG encendido, WP_DEBUG_DISPLAY apagado - y Debug Log Guard vigilando el tamaño. También avisa cuando el log es públicamente accesible, para que el archivo que guardas no filtre tus rutas a cualquiera que las pida.
¿El guardia de tamaño seguirá corriendo si WP-Cron está roto?
No - la comprobación de cada hora depende de WP-Cron, así que si cron no se dispara el guardia tampoco puede ejecutarse. Las acciones manuales y el resumen agrupado no dependen de cron y siguen funcionando igual.
Encoge el log, guarda la evidencia
Debug Log Guard agrupa las repeticiones, transmite el tail y compacta, rota o vacía el archivo con un backup - luego el guardia de tamaño cada hora lo mantiene limitado. Módulo Pro, $79/año por un sitio. Cada plan de pago incluye los 19 módulos.
Consigue Pro - desde $79 al año Guía de sitio caído Todos los planes en la página de precios →