systemd vuelve a estar en el centro del debate dentro de la comunidad Linux. Esta vez la polémica no gira alrededor del arranque del sistema, sino de systemd-journald, el componente encargado de recolectar, almacenar y consultar registros del sistema mediante journalctl.
La discusión se volvió viral después de que una publicación en Hacker News resumiera el problema con un titular contundente: una sola línea de registro podría generar alrededor de 49 KB o más de escrituras en ext4 y más de 110 KB en btrfs. El debate enlaza a un issue abierto en GitHub, donde un usuario reporta IO excesivo causado por systemd-journald en Debian 13 con systemd 257.9.
Idea central: no se trata de que cada sistema Linux esté necesariamente escribiendo 49 KB por cada log. El punto de la polémica es la posible amplificación de escritura: pocos mensajes de texto pueden convertirse en mucha actividad real de disco cuando journald actualiza su formato binario, índices, metadatos y estructuras internas.
1. Qué se está denunciando
El issue más reciente fue abierto el 3 de enero de 2026 bajo el título “Excessive IO caused by systemd-journald”. El reporte indica que el problema se observó con systemd 257.9, Debian 13 y kernel 6.12.57+deb13-amd64. El usuario esperaba que las escrituras de log estuvieran dentro del mismo orden de magnitud que syslog, pero observó una máquina virtual realizando alrededor de 50 IOPS al escribir solo dos líneas de log por segundo.
El propio reporte enlaza a una queja anterior, cerrada en 2020, donde otro usuario aseguró que journald escribía cantidades “extremas” de datos aunque existieran relativamente pocos eventos. En ese caso, el usuario mostró una salida de journalctl con 4.049 líneas y 488.143 bytes, pero afirmó que journald había escrito más de 700 MB al disco.
| Elemento | Detalle reportado |
|---|---|
| Componente | systemd-journald. |
| Issue reciente | #40262: Excessive IO caused by systemd-journald. |
| Distribución reportada | Debian 13. |
| Versión systemd | 257.9, según el reporte. |
| Síntoma | IO elevado al escribir pocas líneas de log por segundo. |
| Debate público | Hacker News viralizó el caso como 49 KB+ en ext4 y 110 KB+ en btrfs por línea de log. |
2. Por qué journald escribe más que un archivo de texto tradicional
systemd-journald no guarda simplemente una línea de texto en un archivo plano. El formato del journal es binario, indexado por campos, permite almacenar datos binarios, búsqueda eficiente, compresión integrada, sellado criptográfico opcional y acceso mediante estructuras internas. La documentación oficial describe que el journal está completamente indexado por campos, es buscable, principalmente append-based y soporta compresión en línea.
Ese diseño tiene ventajas: permite consultar por unidad systemd, PID, usuario, prioridad, boot, servicio, campos estructurados y otros metadatos. Pero también tiene costos: cada entrada puede implicar actualización de objetos internos, tablas hash, arrays de entradas, metadatos y sincronización de archivos. La documentación del formato explica que cada entrada se compone de objetos DATA, FIELD, ENTRY, tablas hash y estructuras para búsqueda.
Lectura técnica: journald no es equivalente a echo "mensaje" >> archivo.log. Es más parecido a escribir en una base de datos local de eventos, con índices y metadatos. Esa complejidad explica por qué puede haber más escrituras reales que bytes visibles en journalctl.
3. La línea de 48 KB: un detalle que alimenta la polémica
La documentación de journald.conf indica que LineMax define la longitud máxima de línea cuando la salida estándar o error estándar de una unidad systemd se convierte en registros del journal. Si no aparece un salto de línea o NUL dentro de ese límite, journald inserta una frontera artificial. El valor por defecto es 48K, descrito como “relativamente grande” pero todavía pensado para que los registros encajen en datagramas de red junto con metadatos.
Esto no significa automáticamente que cada línea ocupe 48 KB en disco. Pero sí ayuda a entender por qué la discusión se volvió tan sensible: si el sistema de logs trabaja con buffers, objetos, metadatos e índices, el tamaño visible de una línea puede no reflejar el costo real de escritura.
4. Por qué el problema importa en servidores, VPS y SSD
En una estación de trabajo moderna, unas escrituras adicionales quizá pasen desapercibidas. Pero en servidores pequeños, VPS, Raspberry Pi, NAS, sistemas embebidos, discos eMMC, tarjetas SD o SSD antiguos, una amplificación de escritura sostenida puede convertirse en un problema real: más IOPS, más latencia, más desgaste y más espacio consumido por logs.
El reporte reciente menciona una VM con tráfico constante de HAProxy generando líneas de log repetitivas y observación de IO después de los mecanismos normales de coalescing del kernel. El usuario sostiene que no se trata solo de que iotop mida mal, sino de tráfico visible a nivel de la máquina virtual.
Advertencia para administradores: si tienes servicios muy verbosos, logs persistentes y almacenamiento limitado, revisa el uso real de journald. No esperes a que /var se llene o a que un SSD pequeño empiece a degradarse.
5. systemd no es solo init: también controla el registro del sistema
Una de las razones por las que systemd genera tanto debate es que no se limita a iniciar servicios. Su ecosistema incluye journald, timers, logind, networkd, resolved, tmpfiles, coredump, nspawn y muchas otras piezas. Para sus defensores, esto ofrece integración, consistencia y administración moderna. Para sus críticos, concentra demasiadas funciones en un solo proyecto.
En el caso de journald, el debate es antiguo. Ya en 2020 se reportaban quejas por IO “anormal” y por el tamaño real de los archivos frente al volumen visible de líneas. El issue de 2020 fue cerrado, pero el tema volvió a abrirse en 2026, lo que muestra que la preocupación no desapareció del todo.
6. Cómo comprobar si tu servidor está afectado
Antes de entrar en el debate ideológico sobre systemd, conviene medir. Un administrador puede revisar cuánto ocupa el journal, cuántos eventos hay, qué servicios generan más ruido y qué procesos están escribiendo al disco.
7. Opciones de configuración para reducir impacto
journald permite configurar almacenamiento, límites de tamaño, retención, compresión, rate limiting, sincronización y nivel máximo de mensajes almacenados. La documentación oficial indica que Storage= puede ser volatile, persistent, auto o none; si se usa persistent, los datos se almacenan preferentemente en /var/log/journal.
También existen límites como SystemMaxUse, SystemKeepFree, SystemMaxFileSize y SystemMaxFiles. Por defecto, el uso máximo se calcula como 10 % del sistema de archivos y el espacio libre a conservar como 15 %, con topes documentados.
Otra opción es modificar SyncIntervalSec, que controla el tiempo antes de sincronizar archivos del journal al disco. La documentación señala que el valor por defecto es 5 minutos y que los mensajes de prioridad CRIT, ALERT o EMERG se sincronizan inmediatamente.
Importante: reducir escrituras puede aumentar el riesgo de perder logs recientes ante un apagón, kernel panic o corte de energía. En servidores críticos, ajusta con criterio y según política de auditoría.
8. Usar almacenamiento volátil: útil para equipos pequeños
En sistemas con tarjetas SD, eMMC, IoT, laboratorios o equipos donde la persistencia de logs no es crítica, puede evaluarse Storage=volatile. Con esta opción, los logs quedan bajo /run/log/journal, es decir, en almacenamiento volátil, y no se escriben persistentemente en /var/log/journal.
Esta medida reduce escrituras persistentes, pero no es adecuada si la organización necesita conservar registros para auditoría, seguridad, investigación de incidentes o cumplimiento normativo.
9. Reducir logs desde la fuente
La mejor forma de reducir presión sobre journald no siempre es tocar journald. Muchas veces el problema está en servicios demasiado verbosos: proxies, contenedores, bases de datos, aplicaciones web, agentes de monitoreo o tareas que registran eventos repetitivos.
- Reducir nivel de log de aplicaciones en producción.
- Evitar registrar cada request HTTP si no aporta valor operativo.
- Separar logs de acceso masivo hacia archivos rotados o sistemas externos.
- Usar agregadores como Loki, OpenSearch, Graylog, syslog-ng o rsyslog cuando corresponda.
- Aplicar rate limiting por servicio en unidades systemd.
- Revisar contenedores que escriben en stdout sin control.
10. ¿Es un bug, un problema de diseño o una mala configuración?
La respuesta todavía no es definitiva. El issue reciente está abierto y etiquetado como bug y journal en el repositorio de systemd. El reporte de 2020 fue cerrado con la etiqueta de journal y necesidad de retroalimentación del reportero.
Desde el punto de vista práctico, hay tres lecturas posibles:
| Interpretación | Qué significa |
|---|---|
| Bug | journald estaría escribiendo mucho más de lo necesario por una falla corregible. |
| Diseño costoso | El formato binario, indexado y con metadatos genera amplificación de escritura inevitable en ciertos escenarios. |
| Mala configuración | Servicios demasiado verbosos, logs persistentes y falta de límites pueden agravar el problema. |
11. Recomendaciones para administradores Linux
- Mide antes de cambiar: usa journalctl, du, iotop, pidstat y métricas del hipervisor.
- Limita el tamaño del journal: configura SystemMaxUse y SystemKeepFree.
- Revisa servicios ruidosos: HAProxy, Nginx, contenedores, bases de datos y agentes.
- No guardes debug en producción: salvo durante ventanas de diagnóstico.
- Evalúa Storage=volatile: solo en sistemas donde perder logs tras reinicio sea aceptable.
- Usa syslog o agregadores externos: si necesitas logs de alto volumen y baja amplificación.
- Protege discos pequeños: especialmente SD, eMMC, SSD antiguos y VPS con IOPS limitados.
- Monitorea /var: alerta antes de que el journal llene la partición.
12. Errores comunes
- Creer que journalctl muestra todo el costo real de escritura.
- No configurar límites de tamaño en servidores pequeños.
- Dejar logs de debug activos indefinidamente.
- Guardar logs persistentes en tarjetas SD sin control.
- No revisar contenedores que escriben demasiado en stdout.
- Confundir tamaño visible del mensaje con IO real generado.
- Desactivar logs totalmente sin considerar auditoría e incidentes.
- No separar logs de acceso masivo de logs del sistema.
- No monitorear desgaste del SSD o IOPS en VPS.
- Entrar en el debate systemd sin medir el caso concreto.
Preguntas clave
¿Cada línea de log ocupa siempre 49 KB?
No necesariamente. El dato de 49 KB en ext4 aparece como resumen viral de la discusión en Hacker News. Lo que sí está documentado en los reportes es la preocupación por IO excesivo y amplificación de escritura en systemd-journald.
¿Por qué journald puede escribir tanto?
Porque no almacena solo texto plano. Usa un formato binario con objetos, campos, entradas, índices, metadatos y compresión. Esa arquitectura mejora búsquedas y estructura, pero puede generar más escrituras internas que un archivo append-only tradicional.
¿Cómo reduzco el impacto?
Configura límites como SystemMaxUse, SystemKeepFree, RuntimeMaxUse, RateLimitBurst y MaxRetentionSec; reduce logs desde las aplicaciones; y evalúa Storage=volatile en equipos donde no se requieran logs persistentes.
¿Conviene desactivar journald?
No como primera medida. En muchas distribuciones modernas es parte central del diagnóstico del sistema. Primero mide, limita y reduce ruido. Solo evalúa cambios drásticos si tienes una política clara de logging alternativo.
¿A quién afecta más?
A sistemas con almacenamiento limitado o sensible a escrituras: Raspberry Pi, NAS, VPS con IOPS limitados, equipos embebidos, tarjetas SD, eMMC, SSD antiguos y servidores con servicios muy verbosos.
Recomendamos
- Comandos básicos que debes aprender para administrar tu servidor Linux
- Guía completa de redes en Linux: comandos, diagnóstico, configuración y solución de problemas
- Por qué los servidores usan Linux: ventajas para empresas y administradores TI
- Ciberseguridad en Linux: 50 herramientas gratuitas para proteger servidores y estaciones
- Cómo instalar Wazuh paso a paso como SIEM y XDR en Linux
En resumen
La polémica sobre systemd-journald vuelve a mostrar una tensión histórica en Linux: integración moderna frente a simplicidad clásica. journald ofrece búsquedas avanzadas, metadatos estructurados, compresión e integración con systemd, pero varios usuarios denuncian que ese diseño puede generar una amplificación de escritura importante en escenarios de logs frecuentes.
El caso viral de los 49 KB por línea en ext4 debe leerse con cuidado: es un resumen del debate público, no una regla universal para todos los servidores. Pero la preocupación de fondo sí es válida: los administradores deben medir cuánto escribe journald, limitar su crecimiento, reducir servicios ruidosos y proteger discos pequeños o sensibles a escrituras.
Conclusión editorial
systemd-journald es poderoso, pero no gratuito en términos de diseño. Para servidores empresariales, laboratorios y sistemas pequeños, la lección es clara: no basta con confiar en la configuración por defecto. Los logs también consumen disco, IOPS y vida útil del almacenamiento. En Linux, incluso una sola línea de registro puede abrir una gran discusión técnica.
