Debian 13: los core dumps llenan tu disco — conserva valor para depurar, elimina el bulto

No te lo imaginas: un solo fallo puede dejar en disco un core dump del tamaño de tu RAM, y Debian 13 lo seguirá haciendo hasta que
tu nodo empiece a fallar escrituras, tu base de datos pase a solo lectura y tu “problema menor de la app” se convierta en un incidente de plataforma.

La solución no es “desactivar core dumps por todos lados” (así acabarás depurando a base de intuición). La solución es una política: conservar los volcados adecuados,
conservarlos por poco tiempo, comprimirlos cuando sea barato y hacer que el sistema pare antes de comerse la máquina.

Qué sucede realmente cuando los discos se llenan con core dumps

Un core dump es una instantánea de la memoria de un proceso en el momento en que murió (normalmente por una señal fatal). Es útil porque contiene el estado
que no puedes reconstruir después: marcos de pila, objetos del heap, estados de hilos y a veces datos sensibles que preferirías no almacenar durante meses.

En Debian moderno, el manejo de core dumps suele pasar por systemd-coredump. El kernel detecta un proceso que falla, consulta
/proc/sys/kernel/core_pattern y o bien escribe un archivo directamente o bien redirige el core a un manejador. Con systemd, ese manejador puede
guardar el volcado en /var/lib/systemd/coredump/ y registrar metadatos en el journal.

El modo de fallo “disco lleno” tiene algunas formas comunes:

• Bucle de fallos de alta frecuencia: un servicio se reinicia, falla inmediatamente y se repite. Cada fallo genera un nuevo volcado.
• Procesos grandes: JVMs, navegadores, runtimes de lenguajes o cualquier cosa con un heap grande. Un volcado puede ser decenas de gigabytes.
• Almacenamiento mal ubicado: los volcados aterrizan en /var que está en tu partición más pequeña (porque alguien decidió así en 2009).
• Sin retención: asumiste “systemd limpiará”. Lo hará, pero solo si está configurado y en su propio horario.
• Seguridad y privacidad: alguien desactiva volcados globalmente para evitar fugas de secretos y pierdes el único artefacto forense que tenías.

Si haces SRE suficiente tiempo, aprendes que los incidentes por disco lleno no son “problemas de almacenamiento”. Son problemas de plano de control: sin límites,
sin propiedad y sin política. Los core dumps son solo una forma particularmente efectiva de hacer esos problemas ruidosos.

Exactamente una cita para todo este artículo, porque somos ingenieros y sabemos contar: La esperanza no es una estrategia. — idea parafraseada atribuida a menudo en círculos de operaciones.

Guía de diagnóstico rápido (primero / segundo / tercero)

Cuando un nodo te avisa porque el disco está al 99%, no empiezas con filosofía. Empiezas con triage. Aquí está la ruta más rápida a “qué está
llenando el disco, por qué ahora y puedo detener la hemorragia sin destruir evidencia?”

Primero: confirma qué sistema de ficheros está lleno y qué está creciendo

• Identifica el punto de montaje lleno y su dispositivo subyacente.
• Confirma si es /var, / o un volumen dedicado.
• Encuentra a los principales culpables por tamaño de directorio, no por conjeturas.

Segundo: confirma que son core dumps e identifica la fuente del fallo

• Revisa el tamaño y las marcas de tiempo en /var/lib/systemd/coredump.
• Usa coredumpctl para ver qué ejecutable está fallando y con qué frecuencia.
• Confirma si es un bucle de reinicio (unidad systemd oscilante) o fallos puntuales.

Tercero: aplica una medida temporal reversible, luego implementa la política

• A corto plazo: limita los volcados, desactiva temporalmente solo el servicio que falla o mueve el almacenamiento.
• Mantén uno o dos volcados representativos para depurar; purga el resto una vez tengas evidencia.
• Después: configura retención (systemd-coredump), límites de tamaño y ubicación de almacenamiento.

Broma #1 (corta y relevante): Los core dumps son como los snacks de oficina: si no se gestionan, se expanden hasta llenar todo el espacio disponible y aún te dejan con hambre.

Hechos interesantes y breve historia (porque este desorden tiene antecedentes)

Algo de contexto ayuda a tomar mejores decisiones. Aquí hay hechos concretos que importan operativamente:

1. Los core dumps son anteriores a Linux: los sistemas Unix volcaron memoria de procesos desde los años 70; la idea es más antigua que la mayoría de los runbooks de producción.
2. “core” no era metafórico: las primeras máquinas usaban memoria core magnética; “core dump” literalmente significaba volcar el contenido de la memoria core.
3. Las ubicaciones por defecto cambiaron con el tiempo: configuraciones antiguas escribían ./core en el directorio de trabajo; las distribuciones modernas suelen encaminar a servicios del sistema.
4. El kernel decide si está permitido volcar: los binarios setuid y contextos privilegiados pueden estar restringidos para volcar por razones de seguridad.
5. El tamaño del volcado no es solo “RAM usada”: mapeos de memoria, huge pages y comportamiento del runtime pueden hacer que los volcados sean más grandes o más pequeños de lo esperado.
6. La compresión no es gratis: comprimir volcados de varios GB consume CPU y puede robar ciclos a la recuperación y mitigación de paging.
7. Los metadatos viven por separado: con systemd, obtienes entradas en el journal sobre un volcado incluso si el archivo está ausente o más tarde rotado.
8. El volcado puede canalizarse: core_pattern puede canalizar a un manejador; por eso verás un | inicial en el patrón.

Tareas prácticas: comandos, qué significa la salida y la decisión que tomas

Esta es la parte que paga el alquiler. A continuación hay tareas reales que puedes ejecutar en Debian 13. Para cada una: comando, salida de ejemplo, qué significa
y la decisión que tomas a partir de ello. Hazlas en orden durante un incidente, o elige las que necesites si ya conoces la forma del problema.

Task 1: Confirm which filesystems are full

cr0x@server:~$ df -hT
Filesystem     Type   Size  Used Avail Use% Mounted on
/dev/sda2      ext4    40G   39G  320M  99% /
/dev/sda3      ext4    20G   19G  400M  98% /var
tmpfs          tmpfs  3.1G   12M  3.1G   1% /run

Significado: Son / y /var los que están en problemas, no algún volumen de datos aleatorio. Eso apunta directamente a logs, cachés de paquetes,
spool y sí, core dumps.

Decisión: Concéntrate en /var y detén las escrituras allí. Si /var es un sistema de ficheros separado, a menudo puedes recuperar más rápido
limpiando /var sin desestabilizar todo el OS.

Task 2: Find the top directories under /var by actual size

cr0x@server:~$ sudo du -xhd1 /var | sort -h
24M     /var/cache
180M    /var/log
1.1G    /var/tmp
17G     /var/lib
19G     /var

Significado: /var/lib es el elemento pesado. Eso es consistente con almacenamiento de systemd-coredump.

Decisión: Profundiza en /var/lib antes de tocar logs o cachés. Tu tiempo de incidente mejora cuando borras lo correcto a la primera.

Task 3: Verify if systemd is storing core dumps on disk

cr0x@server:~$ sudo du -sh /var/lib/systemd/coredump
14G     /var/lib/systemd/coredump

Significado: Confirmado: hay volcados y son grandes.

Decisión: No borres todo en masa todavía. Primero identifica el programa que falla y conserva al menos un volcado representativo.

Task 4: List recent core dumps and identify the offender

cr0x@server:~$ sudo coredumpctl list --no-pager | head
TIME                          PID  UID  GID SIG COREFILE  EXE
Mon 2025-12-29 10:02:41 UTC  9142  998  998  11 present   /usr/bin/myservice
Mon 2025-12-29 10:02:12 UTC  9136  998  998  11 present   /usr/bin/myservice
Mon 2025-12-29 10:01:43 UTC  9129  998  998  11 present   /usr/bin/myservice

Significado: Un binario está volcándose repetidamente. La señal 11 es un segfault, territorio clásico de bucle de fallos.

Decisión: Contén el bucle de fallos. Conserva el volcado más reciente y luego evita que sigan acumulándose volcados.

Task 5: Confirm if it’s a systemd restart loop

cr0x@server:~$ systemctl status myservice.service --no-pager
● myservice.service - Example Service
     Loaded: loaded (/etc/systemd/system/myservice.service; enabled; preset: enabled)
     Active: activating (auto-restart) (Result: core-dump) since Mon 2025-12-29 10:02:42 UTC; 1s ago
    Process: 9142 ExecStart=/usr/bin/myservice (code=dumped, signal=SEGV)
   Main PID: 9142 (code=dumped, signal=SEGV)

Significado: systemd está haciendo exactamente lo que le pediste: reiniciar el servicio y recolectar cores. También está comiéndose tu disco.

Decisión: Detén la unidad (o ajusta la política de reinicios) para detener la hemorragia, luego preserva artefactos para depuración.

Task 6: Stop the service to prevent new dumps (triage move)

cr0x@server:~$ sudo systemctl stop myservice.service
cr0x@server:~$ sudo systemctl is-active myservice.service
inactive

Significado: El bucle de fallos ha parado, al menos en este nodo. El uso de disco debería dejar de crecer.

Decisión: Si esto es un servicio de flota, considera cambiar tráfico o drenar este nodo. Estabiliza primero; depura después.

Task 7: Identify the largest core files

cr0x@server:~$ sudo ls -lhS /var/lib/systemd/coredump | head
-rw------- 1 root root 6.8G Dec 29 10:02 core.myservice.998.3f7a7c1d2c7d4f2d9c9a0d3a9d1d8f0a.9142.1735466561000000.zst
-rw------- 1 root root 6.7G Dec 29 10:02 core.myservice.998.3f7a7c1d2c7d4f2d9c9a0d3a9d1d8f0a.9136.1735466532000000.zst
-rw------- 1 root root 6.7G Dec 29 10:01 core.myservice.998.3f7a7c1d2c7d4f2d9c9a0d3a9d1d8f0a.9129.1735466503000000.zst

Significado: Los volcados ya están comprimidos (fíjate en .zst), y aun así son enormes. Eso indica que la imagen de memoria del proceso es grande.

Decisión: Conserva un volcado (normalmente el más nuevo) para análisis. Planea borrar duplicados antiguos una vez tengas un backtrace.

Task 8: Extract the core dump details without copying it around

cr0x@server:~$ sudo coredumpctl info 9142
           PID: 9142 (myservice)
           UID: 998 (myservice)
           GID: 998 (myservice)
        Signal: 11 (SEGV)
     Timestamp: Mon 2025-12-29 10:02:41 UTC
  Command Line: /usr/bin/myservice --config /etc/myservice/config.yaml
    Executable: /usr/bin/myservice
 Control Group: /system.slice/myservice.service
          Unit: myservice.service
       Storage: /var/lib/systemd/coredump/core.myservice.998.3f7a7c1d2c7d4f2d9c9a0d3a9d1d8f0a.9142.1735466561000000.zst (present)

Significado: Tienes un mapeo preciso de incidente a artefacto: unidad, línea de comando y ruta de almacenamiento.

Decisión: Captura esta información en el canal/incidente antes de borrar nada. Es la ruta de migas para depuración posterior.

Task 9: Get the stack trace (requires debug symbols to be truly useful)

cr0x@server:~$ sudo coredumpctl gdb 9142 -q --batch -ex "thread apply all bt"
[New LWP 9142]
Core was generated by `/usr/bin/myservice --config /etc/myservice/config.yaml'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f2f1a2b9c2a in memcpy () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x000055b8f2b1a2f0 in parse_packet (ctx=0x55b8f3c12000) at src/net/parse.c:217
#2  0x000055b8f2b19d71 in worker_loop () at src/worker.c:88
#3  0x00007f2f1a1691f5 in start_thread () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x00007f2f1a1e8b00 in clone () from /lib/x86_64-linux-gnu/libc.so.6

Significado: Tienes un backtrace y fichero/línea, por lo que probablemente no necesitas 20 volcados idénticos más.

Decisión: Conserva el core más nuevo + el trace. Borra el resto para recuperar disco. Si no puedes obtener símbolos, guarda un volcado y céntrate en recolectar símbolos después.

Task 10: Check current systemd-coredump configuration

cr0x@server:~$ sudo systemd-analyze cat-config systemd/coredump.conf
# /etc/systemd/coredump.conf
[Coredump]
Storage=external
Compress=yes
ProcessSizeMax=8G
ExternalSizeMax=8G
MaxUse=16G
KeepFree=2G

Significado: Existen límites, pero pueden ser demasiado generosos para el tamaño de tu /var (o para tu tasa de fallos).

Decisión: Ajusta MaxUse y sube KeepFree, o mueve el almacenamiento a un sistema de ficheros dedicado.

Task 11: Verify what the kernel will do with core dumps (core_pattern)

cr0x@server:~$ cat /proc/sys/kernel/core_pattern
|/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e

Significado: Los cores se canalizan hacia systemd-coredump, no son escritos directamente por el kernel a una ruta de archivo.

Decisión: Arregla la retención vía la configuración de systemd-coredump (no editando un patrón de ruta y esperando que funcione).

Task 12: Check global core size limit (ulimit) for the current shell

cr0x@server:~$ ulimit -c
unlimited

Significado: Al menos en tu shell, el tamaño de core no está limitado. Para servicios, el límite efectivo puede venir de la configuración de la unidad systemd.

Decisión: Establece límites en la unidad (preferido) o vía PAM limits para sesiones interactivas, dependiendo del contexto.

Task 13: Check core limit applied to a running service process

cr0x@server:~$ pidof myservice
9210
cr0x@server:~$ grep -E '^Max core file size' /proc/9210/limits
Max core file size        unlimited            unlimited            bytes

Significado: El servicio puede generar volcados de tamaño completo.

Decisión: Si quieres “algunos” cores pero no enormes, limita a un tamaño que preserve pilas (a menudo cientos de MB) sin almacenar heaps completos.

Task 14: Confirm if journald is also under pressure

cr0x@server:~$ journalctl --disk-usage
Archived and active journals take up 1.4G in the file system.

Significado: Los journals no son el principal culpable aquí, pero 1.4G aún puede importar en un /var pequeño.

Decisión: No “vacíes” el journal como primera medida si los cores ocupan 14G. Arregla el problema real primero.

Task 15: Free space safely by deleting old dumps after preserving one

cr0x@server:~$ sudo coredumpctl list --no-pager | awk '/myservice/ {print $5}' | head
present
present
present
cr0x@server:~$ sudo rm -f /var/lib/systemd/coredump/core.myservice.*.9136.*.zst /var/lib/systemd/coredump/core.myservice.*.9129.*.zst
cr0x@server:~$ df -h /var
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3        20G   12G  7.4G  62% /var

Significado: Has ganado espacio de respiración y no has borrado todo a ciegas.

Decisión: Ahora implementa límites correctos para que esto no vuelva a ocurrir. Los borrados manuales son para hoy, no para la próxima semana.

Una política de retención sensata para Debian 13 (conservar valor, eliminar bulto)

Quieres suficientes artefactos de crash para responder: “¿qué pasó?” No quieres una máquina del tiempo con cada fallo del último trimestre. Los core dumps son
artefactos de alta señal y alto coste.

Una buena política tiene cuatro partes:

• Alcance: qué procesos pueden volcar core (todos? solo servicios críticos? solo en staging?).
• Límites de tamaño: límites por proceso y globales que encajen con la realidad de tus discos.
• Retención: conservar una ventana pequeña (por tiempo y por espacio), rotar agresivamente.
• Acceso y privacidad: los core dumps pueden incluir credenciales, tokens, datos de clientes y secretos descifrados. Trátalos como sensibles.

Aquí la versión opinada para la mayoría de flotas en producción:

• Habilita core dumps para servicios donde realmente depuras fallos (usualmente sí).
• Limita los volcados por proceso a algo que preserve backtraces y pilas de hilos (a menudo 256M–2G, según lenguaje/runtime).
• Mantén como máximo unos pocos gigabytes por nodo o por filesystem de volcados, y reserva espacio libre de seguridad.
• Prefiere almacenar volcados en un filesystem dedicado (o al menos en un directorio con cuotas/límites previsibles).
• Envía metadatos (no volcados) de forma centralizada. Mueve volcados fuera del host solo cuando decidas que son necesarios.

Si te tienta desactivar core dumps por completo, pregúntate: ¿tienes telemetría de crash reproducible, stacks simbolizados y pasos de reproducción deterministas?
Si la respuesta es sí, tal vez. Si no, estás eligiendo incidentes más largos.

Broma #2 (la segunda y la última): Desactivar core dumps por todas partes es como quitar detectores de humo porque hacen ruido—silencio, sí; situación mejorada, no.

systemd-coredump: configuración que funciona en producción

En Debian 13, systemd es tu amigo aquí, pero solo si le dices qué significa “suficiente”. El archivo suele ser:
/etc/systemd/coredump.conf (y drop-ins en /etc/systemd/coredump.conf.d/).

Perillas clave que deberías cuidar

• Storage= Dónde van los volcados: archivos externos, journal, ambos o ninguno.
• Compress= Si comprimir los archivos core (habitualmente zstd). Útil, pero vigila la CPU durante tormentas de fallos.
• ProcessSizeMax= Tamaño máximo del volcado del proceso elegible para manejo.
• ExternalSizeMax= Tamaño máximo de un core externo individual guardado.
• MaxUse= Espacio máximo en disco que puede consumir systemd-coredump en total.
• KeepFree= Cuánto espacio libre mantener en el filesystem que alberga los volcados.

Una base práctica para un nodo con /var de 20–40G es algo como:

• MaxUse=2G a 6G según cuánto valores los volcados frente a la disponibilidad.
• KeepFree=2G a 5G para que journald, actualizaciones de paquetes y el runtime normal no mueran.
• ExternalSizeMax=512M a 2G para conservar trazas de pila sin guardar siempre heaps de varios GB.

No tienes que adivinar. Puedes elegir un valor menor que “llenar el disco” y aumentarlo más tarde si te falta información.

Ejemplo: apretar la retención de inmediato (y de forma segura)

cr0x@server:~$ sudo install -d /etc/systemd/coredump.conf.d
cr0x@server:~$ cat <<'EOF' | sudo tee /etc/systemd/coredump.conf.d/99-retention.conf
[Coredump]
Storage=external
Compress=yes
ExternalSizeMax=1G
MaxUse=4G
KeepFree=4G
EOF
cr0x@server:~$ sudo systemctl daemon-reload

Significado: Has establecido techos globales duros. Incluso si un servicio se descontrola, el nodo seguirá respirando.

Decisión: Si rutinariamente necesitas heaps completos para análisis de corrupción de memoria, sube ExternalSizeMax pero mueve los volcados fuera de /var.
No pretendas tener volcados de 8G en un filesystem de 20G y estar feliz.

Cómo ocurre realmente la rotación

systemd-coredump aplica su propia lógica para retener/borrar cores cuando se alcanzan límites. Eso está bien, pero no es instantáneo como una cuota.
Si estás en un bucle de fallos, sigue interesándote detener la unidad; de lo contrario seguirás generando CPU y E/S para volcados que se eliminan de inmediato.

ulimit, core_pattern y por qué “funcionó en mi portátil” te miente

El volcado de core tiene tres capas que se confunden constantemente:

1. Elegibilidad del kernel: ¿está habilitado el volcado de core para este contexto de fallo?
2. Límites del proceso: ¿cuál es el tamaño máximo de core que el proceso puede escribir?
3. Manejador de core: ¿dónde va el core y qué política se aplica tras la creación?

Los límites a nivel de unidad systemd vencen a tu shell

Puedes poner ulimit -c en una shell y sentirte productivo. Al servicio no le importa. Para servicios systemd, usa:
LimitCORE= en el archivo de unidad o en un drop-in.

Ejemplo: limitar cores para un servicio sin tocar el resto del nodo:

cr0x@server:~$ sudo systemctl edit myservice.service

cr0x@server:~$ cat /etc/systemd/system/myservice.service.d/override.conf
[Service]
LimitCORE=512M

cr0x@server:~$ sudo systemctl daemon-reload
cr0x@server:~$ sudo systemctl restart myservice.service

Significado: Aunque el proceso sea grande, el archivo de volcado no podrá exceder 512M. A menudo eso es suficiente para una traza útil.

Decisión: Para servicios en bucle de fallos, limita inmediatamente para detener el crecimiento del disco y conservar valor de depuración.

core_pattern es la centralita

Si /proc/sys/kernel/core_pattern canaliza hacia systemd-coredump, tus expectativas de “dónde están los archivos core” deben cambiar.
Los encontrarás bajo la gestión de systemd, no en tu CWD.

Si tu organización tiene manejadores personalizados (subidores, filtros), valídalos. Un manejador de core con bugs puede fallar abierto (dejando volcados) o fallar cerrado (bloqueando y
deteniendo la salida del proceso en fallo). Ninguno es divertido.

Estrategia de almacenamiento: dónde deben vivir los core dumps (y dónde no)

Trata los core dumps como mini-backups de memoria: grandes, sensibles y ocasionalmente invaluables. Eso sugiere algunas reglas de almacenamiento.

Regla 1: No almacenes volcados en un /var pequeño si puedes evitarlo

Muchas imágenes todavía reservan una pequeña partición de /var porque “se ve limpio”. También es como terminas con un OS incapaz de escribir estado durante un incidente.
Si tu layout de distribución aísla /var, planifica dónde irán los volcados.

Regla 2: Un filesystem dedicado vence a una limpieza heroica

La ganancia operativa es la aislación: si los cores llenan su propio filesystem, el nodo puede seguir registrando, actualizando paquetes, escribiendo estado en runtime y recuperarse.
Puedes montar un volumen dedicado en /var/lib/systemd/coredump o usar un bind-mount.

Ejemplo: crea un punto de montaje y confirma que es un sistema de ficheros separado (la provisión depende de tu entorno):

cr0x@server:~$ sudo findmnt /var/lib/systemd/coredump
TARGET                       SOURCE    FSTYPE OPTIONS
/var/lib/systemd/coredump     /dev/sdb1 ext4   rw,relatime

Significado: Los volcados están aislados del /var en general. Ahora tu peor caso es “no más volcados”, no “nodo muerto”.

Regla 3: Planifica privacidad (los core dumps son datos)

Los core dumps pueden contener:

• Tokens de API en memoria
• Payloads descifrados
• Identificadores de clientes
• Claves de cifrado (sí, a veces)

Eso significa: restringe permisos, limita la retención y sé deliberado sobre quién puede extraer volcados para depuración.
“Root puede leerlo” no es una política.

Regla 4: Considera mantener metadatos de forma central, no los volcados

En muchas organizaciones, el mejor compromiso es:

• Mantener volcados localmente por una ventana corta.
• Conservar solo metadatos (marcas temporales, ejecutable, unidad, señal, backtrace) en registros de incidentes o logs centralizados.
• Copiar el volcado fuera del host solo cuando hayas decidido que es necesario.

Esto evita convertir tu canal de logs en un sistema de transporte de datos a granel. Esos sistemas siempre “funcionan”, hasta que dejan de hacerlo.

Tres mini-historias corporativas de las minas de volcados

Mini-historia 1: El incidente causado por una suposición errónea

Una empresa mediana desplegó una nueva imagen basada en Debian a un conjunto de nodos API. La imagen tenía un esquema de particiones ordenado: raíz pequeña, /var separado
y un volumen de datos para el estado de la aplicación. Todo el mundo se sentía maduro.

Una semana después, un nodo empezó a oscilar. No toda la flota—solo uno. Siguió reiniciando un servicio worker y, tras un rato, dejó de responder a despliegues. Luego dejó de aceptar logins.
El nodo no estaba muerto; solo era incapaz de escribir en disco en los sitios que importaban.

La suposición errónea fue simple: “Los core dumps van al volumen de datos”. Alguien había visto archivos core en un directorio de aplicación años atrás y asumió que seguía siendo el predeterminado.
En esta imagen, systemd-coredump almacenaba volcados en /var/lib/systemd/coredump, y /var era de 10–20G.

Cada fallo creaba un volcado comprimido de varios GB. systemd reiniciaba el servicio. Llegaron más volcados. /var se llenó. Journald empezó a descartar mensajes. Las actualizaciones de paquetes fallaron.
El nodo no podía escribir suficiente estado para recuperarse limpiamente.

La solución no fue ingeniosa: detener el servicio, conservar un volcado, borrar el resto y mover el almacenamiento de core a un montaje dedicado. Luego ajustar KeepFree
para que futuras tormentas de fallos no pudieran dejar sin espacio al OS. La solución mayor fue cultural: dejar de asumir defaults y empezar a verificarlos con comandos que devuelvan hechos.

Mini-historia 2: La optimización que salió mal

Otra org quería “mejor depuración”, así que habilitaron core dumps ampliamente y aumentaron la retención. También activaron compresión y subieron límites de tamaño, porque “el almacenamiento es barato”.

Estuvo bien… hasta que una release introdujo un fallo raro en un proceso de alto throughput. La tasa de fallos no era enorme, pero tampoco pequeña. En horas punta, se generaban cores regularmente, cada uno de varios gigabytes incluso tras compresión.

El problema vino desde un ángulo que nadie modeló: contención de CPU durante la recuperación. Comprimir volcados grandes es trabajo de CPU. Cuando empezaron los fallos, el sistema dedicó una porción medible de CPU a comprimir instantáneas de memoria mientras también intentaba aliviar carga, reiniciar servicios y servir tráfico.

Su “optimización para depuración” se tradujo en brownouts prolongados. No una caída total, peor: una hemorragia lenta donde las peticiones timeoutaban y los reintentos amplificaban la carga. El oncall podía ver los cores y los incidentes, pero la plataforma se movía como si fuera miel.

La política final fue más matizada: limitar el tamaño de core por servicio, y en algunos casos almacenar solo metadatos más un volcado mínimo. Para los pocos deep dives, reproducirían en staging con volcados completos habilitados. El valor de depuración subió y el dolor en incidentes bajó.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una compañía relacionada con finanzas tenía una costumbre que nadie celebraba: cada unidad crítica tenía un drop-in systemd con límites de recursos pequeños,
incluyendo LimitCORE. Era parte de la “plantilla de unidad dorada”, como fijar timeouts y políticas de reinicio.

Una actualización de una librería de terceros provocó un segfault en un servicio en background en un subconjunto de nodos. El servicio falló, systemd lo reinició y sí,
se generaron core dumps. Pero estaban limitados a unos pocos cientos de megabytes.

Los nodos se mantuvieron sanos. Los logs siguieron fluyendo. Los despliegues continuaron. El incidente fue molesto pero controlado. Los ingenieros sacaron un volcado,
obtuvieron un backtrace, correlacionaron la ruta de código fallida y revertieron la librería en horario planificado.

Nadie obtuvo un momento de héroe. Ese es el punto. El límite aburrido permitió que el equipo depurara sin sacrificar disponibilidad. También evitó que el equipo de seguridad entrara en pánico por enormes snapshots de memoria sensible acumulándose en discos.

Errores comunes: síntoma → causa raíz → solución

Estos son los reincidentes. Cada uno incluye una solución específica, no un póster motivacional.

Mistake 1: “El disco está lleno, borra /var/log”

Síntoma: El uso del disco sube rápido; los logs reciben la culpa primero; borras journals y sigues teniendo el problema mañana.

Causa raíz: Los core dumps en /var/lib/systemd/coredump son los datos de verdad.

Solución: Mide con du, luego limita y rota core dumps. Borra volcados duplicados solo después de capturar al menos un backtrace.

Mistake 2: “Desactivar core dumps globalmente”

Síntoma: Los incidentes se vuelven más difíciles de depurar; los tickets de “se cayó” se eternizan; la culpa pasa a “infra” porque no queda evidencia.

Causa raíz: Una respuesta contundente al estrés por disco o a preocupaciones de privacidad.

Solución: Mantén los cores habilitados pero limitados. Usa LimitCORE por servicio, y MaxUse/KeepFree a nivel global.
Trata los volcados como sensibles y acorta la retención.

Mistake 3: “Pusimos MaxUse, así que estamos seguros”

Síntoma: El disco aún llega al 100% durante tormentas de fallos; los nodos siguen inestables.

Causa raíz: Los límites no actúan como cuotas instantáneas; el bucle de fallos sigue generando datos y además estás quemando CPU.

Solución: Detén la unidad ofensora primero. Luego configura retención. Los límites no sustituyen a la contención.

Mistake 4: “Los cores son pequeños porque están comprimidos”

Síntoma: Ves .zst y asumes que estás bien, hasta que ya no lo estás.

Causa raíz: La ratio de compresión varía mucho; heaps grandes y regiones mapeadas todavía producen volcados de varios GB.

Solución: Limita tamaño. Verifica tamaños reales con ls -lhS. No razones por extensión de archivo.

Mistake 5: “Nuestro servicio no puede estar en bucle; lo notaríamos”

Síntoma: De repente tienes docenas de cores; el servicio parece “mayormente bien” porque un balanceador oculta un nodo malo.

Causa raíz: Fallo parcial enmascarado por redundancia; un nodo está volcando cores en silencio.

Solución: Alerta por tasa de creación de core dumps y por bucles de reinicio de unidades systemd (Result: core-dump). Usa coredumpctl list
durante el triage.

Mistake 6: “Movimos los cores fuera de /var, listo”

Síntoma: La partición de core se llena y ahora pierdes artefactos de depuración—todavía no es ideal.

Causa raíz: Aislar sin retención es simplemente mover el fuego.

Solución: Aisla y establece MaxUse/KeepFree/ExternalSizeMax. Añade monitorización.

Listas de comprobación / plan paso a paso

Checklist A: Durante un incidente activo de disco lleno

1. Confirma qué está lleno: df -hT.
2. Identifica el directorio que más crece: sudo du -xhd1 /var | sort -h.
3. Confirma que los core dumps son la mayor parte: sudo du -sh /var/lib/systemd/coredump.
4. Identifica al culpable: sudo coredumpctl list.
5. Detén el bucle de fallos: systemctl status ..., luego systemctl stop ... o aisla el nodo.
6. Preserva un volcado representativo y metadatos: coredumpctl info PID.
7. Obtén un backtrace si es posible: coredumpctl gdb PID.
8. Borra duplicados para recuperar disco (quirúrgicamente).
9. Establece límites de retención inmediatos (coredump.conf.d).
10. Solo entonces reinicia el servicio en condiciones controladas.

Checklist B: Endurecimiento después del incidente (parte que previene repeticiones)

1. Crea o confirma un filesystem de volcados dedicado o al menos suficiente espacio de seguridad en /var.
2. Establece MaxUse y KeepFree basándote en tus nodos más pequeños, no en los más grandes.
3. Configura ExternalSizeMax y/o LimitCORE por servicio.
4. Define quién puede acceder a los volcados y cuánto tiempo persisten.
5. Asegura que los símbolos de depuración estén disponibles donde se analizan los volcados (sin llevar toolchains completos a cada nodo).
6. Añade alertas sobre:
   • espacio libre del filesystem de volcados
   • tasa de creación de core dumps
   • bucles de reinicio de unidades systemd con resultado core-dump
7. Documenta la regla “conservar un volcado, purgar duplicados” en tu runbook.

Preguntas frecuentes

1) ¿Debería desactivar los core dumps en producción?

Normalmente no. Desactívalos selectivamente si tienes una razón potente (cargas sensibles con controles estrictos o ya tienes telemetría de crash equivalente).
Prefiere primero limitar tamaños y retención.

2) ¿Dónde guarda Debian 13 los core dumps por defecto?

Comúnmente bajo /var/lib/systemd/coredump/ cuando se usa systemd-coredump. Confírmalo con cat /proc/sys/kernel/core_pattern
y coredumpctl info.

3) ¿Por qué mis archivos core ya están comprimidos pero siguen siendo enormes?

Porque la compresión no cambia el hecho de que estás capturando una gran imagen de memoria. Heaps grandes, ficheros mapeados y ciertos patrones de memoria se comprimen mal.
Limita ExternalSizeMax y/o LimitCORE.

4) ¿Cuál es la forma más rápida de identificar qué está fallando?

sudo coredumpctl list muestra el ejecutable y si hay un archivo core presente. Combínalo con systemctl status para detectar bucles de reinicio.

5) ¿Puedo conservar solo metadatos y no el volcado completo?

Sí. Puedes configurar el comportamiento de almacenamiento para que solo se conserven metadatos, pero ten cuidado: cuando necesites un volcado, no lo tendrás.
Un compromiso común es conservar volcados pequeños y limitados más los metadatos.

6) ¿Cómo limito el tamaño del core para un servicio sin cambiar todo el nodo?

Añade un drop-in systemd con LimitCORE=... para esa unidad. Ese es el punto de control operacional más limpio para servicios.

7) ¿Por qué el disco aún sube incluso después de poner MaxUse en coredump.conf?

Porque aún puedes generar cores rápidamente durante un bucle de fallos y la aplicación de límites no es una cuota instantánea perfecta. Detén la unidad primero y luego afina
la retención. Los límites reducen el bloat en estado estable; la contención arregla las tormentas de fallos.

8) ¿Y la privacidad y secretos en los core dumps?

Asume que los cores contienen secretos. Restringe el acceso, acorta la retención y evita enviar volcados de forma amplia. Trátalos como artefactos sensibles de incidentes, no como logs.

9) ¿Necesito símbolos de depuración en cada nodo de producción?

No necesariamente. Necesitas una forma fiable de simbolizar stacks en algún sitio. Muchos equipos mantienen símbolos en un entorno de depuración dedicado y solo extraen
el volcado necesario cuando es preciso (con controles de acceso adecuados).

10) ¿Es seguro borrar core dumps?

Sí, después de haber preservado al menos un volcado representativo y capturado metadatos/backtraces. El riesgo no es la estabilidad del sistema; el riesgo es perder
valor forense. Sé intencional: guarda uno, borra duplicados.

Conclusión: siguientes pasos que no te morderán más tarde

Los core dumps son oro para depuración y kryptonita operacional. Debian 13 te da las herramientas para quedarte con el oro y desechar la kryptonita, pero no lo hará automáticamente.
Tienes que elegir límites que se ajusten a tus discos y a tu tolerancia a incidentes.

Haz esto a continuación, en este orden:

1. En un nodo, verifica dónde van los volcados y cuán grandes son: coredumpctl list, du -sh /var/lib/systemd/coredump.
2. Configura retención global: MaxUse y KeepFree en un drop-in de coredump.
3. Establece límites por servicio para los sospechosos habituales (heaps grandes, componentes propensos a fallar): LimitCORE.
4. Aísla el almacenamiento si es posible: dedica un filesystem o un montaje para los volcados.
5. Hazlo observable: alerta por tasa de volcados y por bucles de reinicio con core dumps.

El objetivo no es “nunca generar un core dump”. El objetivo es: cuando algo se rompa a las 03:00, obtengas un artefacto útil y un nodo que aún pueda arrancar.