Los logs de Docker llenan el disco: truncar y limitar

truncate -s 0 "$(docker inspect --format '{{.LogPath}}' api)" vacía el log de un contenedor en marcha y libera el espacio al momento, sin reiniciar nada. Aquí no se usa rm: el demonio sigue escribiendo en el archivo borrado, el espacio no vuelve y docker logs queda roto hasta que el contenedor se reinicie.

1. Primero mira qué ocupa Docker

$ clai cuánto espacio en disco usa docker→ docker system dfTYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLEImages          48        14        28.88GB   20GB (69%)Containers      17        10        4.631MB   513.8kB (11%)Local Volumes   38        7         6.349GB   4.084GB (64%)Build Cache     181       0         0B        0B

Los logs no aparecen en esta tabla: la fila Containers cuenta solo la capa de escritura. Si df dice que el disco está lleno y docker system df está tranquilo, los logs son el sospechoso.

2. Encuentra el contenedor que más escribe

$ clai muestra el tamaño del archivo de log de cada contenedor, de mayor a menor→ docker ps -q | xargs docker inspect --format '{{.LogPath}} {{.Name}}' | while read -r p n; do printf '%s\t%s\n' "$(du -h "$p" | cut -f1)" "${n#/}"; done | LC_ALL=C sort -rh | head -36.1M	api3.2M	worker1.9M	cache

LogPath es la única forma fiable de localizar el archivo: cambia entre instalaciones rootful y rootless. LC_ALL=C no es adorno: en una configuración regional con coma decimal, sort -h coloca 844K por encima de 6.1M.

3. Trunca el log de un contenedor en marcha

$ clai vacía el log del contenedor api sin pararlo→ truncate -s 0 "$(docker inspect --format '{{.LogPath}}' api)"

El contenedor sigue escribiendo en el mismo descriptor de archivo, el flujo no se corta y el espacio vuelve de inmediato. Es el comando que quieres durante un incidente.

4. La trampa: rm en lugar de truncate

$ clai borra el archivo de log del contenedor api→ rm "$(docker inspect --format '{{.LogPath}}' api)"⚠ CAUTION — después de esto docker logs queda roto hasta reiniciar el contenedor

docker logs responde Error grabbing logs: open …-json.log: no such file or directory, y el archivo no reaparece solo. El demonio mantiene abierto el archivo borrado, así que el espacio tampoco se libera: pierdes la salida y conservas el problema.

5. Para que no vuelva a pasar

$ clai arranca un contenedor con rotación de log de 10 megabytes y tres archivos→ docker run -d --log-opt max-size=10m --log-opt max-file=3 --name api alpine sleep 600

El tamaño de un archivo por el número de archivos es el techo: aquí 30 MB. Póntelo a cada contenedor hablador.

6. Comprueba si un contenedor en marcha tiene límite

$ clai muestra la configuración de logging del contenedor api→ docker inspect -f '{{json .HostConfig.LogConfig}}' api{"Type":"json-file","Config":{"max-file":"3","max-size":"10m"}}

Un "Config":{} vacío significa que no hay ningún límite y el archivo crecerá hasta agotar el disco. Así se ve exactamente un contenedor arrancado sin esas opciones.

Gotchas

• Truncar libera solo el archivo activo. Un contenedor limitado a max-size=1m --log-opt max-file=2 escribió 20000 líneas y docker logs las mostraba todas. Tras truncar el archivo activo quedaban 10122 líneas: el resto vive en el rotado …-json.log.1. Los rotados se borran, el activo se trunca.
• daemon.json no afecta a los contenedores existentes. log-opts en /etc/docker/daemon.json se lee al crear el contenedor. Los que ya corren mantienen su configuración anterior hasta que los recrees.
• sort -h depende de la configuración regional. En una locale rusa o alemana 6.1M no se interpreta como número y el log más gordo acaba en mitad de la lista. Pon LC_ALL=C delante de sort.

Related questions

¿Por qué docker system df no muestra los logs? Cuenta imágenes, capas de escritura, volúmenes y caché de compilación. Los archivos json de log están al lado, en el directorio del contenedor, y nunca entran en esa tabla.

¿Cómo limito los logs de todos los contenedores a la vez? Añade "log-driver": "json-file" y "log-opts": {"max-size": "10m", "max-file": "3"} a /etc/docker/daemon.json, reinicia el demonio y recrea los contenedores.

¿Puedo no escribir logs en disco? Sí, --log-driver none desactiva la recogida, pero entonces docker logs no muestra nada. El término medio es el driver local, que rota por defecto.

See also

• Recuperar espacio en disco de Docker
• df dice lleno, du dice vacío
• journalctl: los logs de un servicio

CliAI convierte la frase de arriba en el comando exacto y marca la variante con rm como CAUTION antes de ejecutar nada. Instálalo en una línea.