Problema

En entornos de homelab o producción ligera es frecuente ejecutar servicios (DNS, VPN, monitoreo) dentro de contenedores LXC gestionados por Proxmox. Un patrón recurrente es que, tras semanas o meses de operación, el contenedor comienza a fallar: los procesos se reinician, los logs muestran “no space left on device” y, como consecuencia, la red deja de responder. El síntoma visible suele ser una pérdida de conectividad DNS o una caída del propio servicio, aunque el host sigue funcionando.

Este comportamiento no es exclusivo de una aplicación concreta; cualquier proceso que escriba datos de forma continua (logs, bases de datos, cachés) puede llenar la partición raíz del contenedor si el tamaño asignado fue demasiado conservador. Cuando el espacio se agota, el kernel devuelve ENOSPC y la mayoría de los demonios abortan, generando bucles de reinicio que complican la detección del origen real del problema.

Causa

  1. Asignación de disco insuficiente en la creación del LXC
    Los scripts comunitarios de Proxmox suelen crear contenedores con 2‑4 GB de rootfs por defecto. Esa cantidad basta para una instalación mínima, pero no para servicios que generan archivos de registro o bases de datos en tiempo real.

  2. Crecimiento inesperado de logs
    Servicios como AdGuard Home, Pi-hole, Nextcloud o bases de datos SQLite escriben logs sin rotación automática o con una política de retención demasiado amplia. Con el tiempo, los archivos pueden ocupar varios cientos de megabytes.

  3. Archivos temporales y cachés no limpiados
    Algunas aplicaciones crean archivos temporales en /tmp o /var/cache y no los eliminan. En contenedores sin un proceso de limpieza periódico, esos directorios se convierten en sumideros de espacio.

  4. Snapshots o backups dentro del contenedor
    Copias de seguridad locales (por ejemplo, rsync a una carpeta dentro del contenedor) duplican datos y pueden consumir rápidamente el espacio disponible.

  5. Falta de monitoreo de uso de disco
    Sin alertas de umbral, el administrador no recibe aviso antes de que el espacio se agote, lo que lleva a una falla inesperada del servicio.

Solución

Una estrategia eficaz combina tres pasos: diagnóstico rápido, limpieza inmediata y ajuste permanente del tamaño del disco.

1. Diagnóstico rápido

Ejecuta df -h dentro del contenedor para confirmar que la raíz está al 100 %:

df -h /

Revisa los directorios que más espacio consumen con du:

du -h --max-depth=1 / | sort -hr | head -n 10

Si el culpable son logs, normalmente aparecerán bajo /var/log o dentro del directorio de datos de la aplicación (/opt/adguardhome/work, /var/lib/...).

2. Limpieza inmediata

  • Rotar o borrar logs antiguos

    find /var/log -type f -name "*.log" -mtime +7 -exec rm -f {} \;

    (elimina logs mayores a 7 días; ajusta según política).

  • Vaciar cachés temporales

    rm -rf /tmp/*
rm -rf /var/cache/*

  • Eliminar snapshots locales

    find /path/to/backups -type f -mtime +30 -exec rm -f {} \;

Después de la limpieza, verifica el espacio disponible con df -h nuevamente.

3. Redimensionar la partición del contenedor

Proxmox permite ampliar el disco de un LXC sin detenerlo (si el almacenamiento subyacente lo soporta). Desde el host:

pct resize <CTID> rootfs +5G

Reemplaza <CTID> por el ID del contenedor y +5G por el incremento necesario. Si prefieres establecer un tamaño absoluto:

pct resize <CTID> rootfs 10G

Una vez redimensionado, dentro del contenedor ejecuta resize2fs (para ext4) o el comando correspondiente al sistema de archivos:

resize2fs /dev/mapper/pct-<CTID>-root

4. Implementar rotación automática y alertas

  • Logrotate: crea una regla simple en /etc/logrotate.d/<service> para rotar cada día y mantener 7 copias.
  • Monitoreo: usa smartctl, zabbix, prometheus node_exporter o simples cron jobs que envíen un correo cuando df cruce el 80 %:
*/15 * * * * root df -h / | awk '/%/ {if ($5+0 > 80) print "ALERTA: uso de disco >80% en $(hostname)"}' | mail -s "Disk usage alert" admin@example.com

Cuándo aplicar esta solución

  • Síntomas: servicios que se reinician, logs con ENOSPC, pérdida de DNS o de cualquier funcionalidad dependiente del contenedor.
  • Entorno: LXC bajo Proxmox, OpenVZ, o cualquier contenedor que utilice una partición raíz estática.
  • No aplica: cuando el error proviene de un disco externo montado en el contenedor (p.ej., NFS) o cuando el host físico ya está sin espacio; en esos casos el problema debe resolverse a nivel del host.

Código

# 1. Ver uso de disco
df -h /

# 2. Identificar los mayores consumidores
du -h --max-depth=1 / | sort -hr | head -n 10

# 3. Limpiar logs mayores a 7 días
find /var/log -type f -name "*.log" -mtime +7 -exec rm -f {} \;

# 4. Vaciar cachés temporales
rm -rf /tmp/*
rm -rf /var/cache/*

# 5. Redimensionar LXC desde el host (ejemplo CTID=101, +5G)
pct resize 101 rootfs +5G

# 6. Ajustar tamaño del FS dentro del contenedor (ext4)
resize2fs /dev/mapper/pct-101-root

# 7. Configurar logrotate básico (ejemplo para AdGuard Home)
cat > /etc/logrotate.d/adguardhome <<'EOF'
/opt/adguardhome/work/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    copytruncate
}
EOF

# 8. Cron alerta de uso >80%
cat > /etc/cron.d/disk_alert <<'EOF'
*/15 * * * * root df -h / | awk '/%/ {if ($5+0 > 80) print "ALERTA: uso de disco >80% en $(hostname)"}' | mail -s "Disk usage alert" admin@example.com
EOF

Verificación

  1. Reinicia el servicio (p.ej., systemctl restart adguardhome) y observa que permanece activo sin volver a crashear.
  2. Comprueba el espacio: df -h / debe mostrar al menos 20 % libre.
  3. Genera carga (consulta DNS o escribe logs) y verifica que el contenedor no vuelve a reiniciarse.
  4. Revisa los logs de rotación (/var/lib/logrotate/status) para confirmar que logrotate está ejecutándose.
  5. Simula un umbral: crea un archivo grande temporalmente (dd if=/dev/zero of=/tmp/fill bs=1M count=500) y verifica que el cron envía la alerta cuando el uso supera el 80 %.

Notas adicionales

  • Cuando uses pct resize, el tipo de almacenamiento (LVM, ZFS, directory) determina si el contenedor necesita estar detenido. En ZFS, la expansión suele ser en línea; en LVM, a veces es necesario parar el contenedor.
  • Si el contenedor aloja bases de datos SQLite, considera ejecutar VACUUM; después de limpiar datos para recuperar espacio interno.
  • Evita montar volúmenes externos dentro del contenedor para logs críticos; mantenerlos en el host facilita la gestión de espacio y la creación de snapshots.
  • En entornos con varios contenedores, crea una política de tamaño mínimo (p.ej., 10 GB) y documenta la justificación para evitar sorpresas en el futuro.