Error de actualización: espacio en disco insuficiente -- ¿archivos overlay excesivos?

Bueno, suspiro… estoy atascado en una actualización fallida.

Tengo un VPS de 25G, usando la instalación de Docker compatible.

La actualización de docker_manager a través del panel de administración fue bien.

La actualización de Discourse de v3.2.0.beta1 +125 a v3.2.0.beta3 +325 a través del panel de administración falló, así que intenté una instalación desde la línea de comandos:

cd /var/discourse
git pull
./launcher rebuild app

…lo que también falló:

Tienes menos de 5 GB de espacio libre en el disco donde se encuentra /var/lib/docker. Necesitarás más espacio para continuar
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda2        23G   22G  640M  98% /

Aparentemente debido a dos archivos “overlay” de 18G:

root@forum:/var/discourse# df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs            95M  1.4M   94M   2% /run
/dev/vda2        23G   18G  4.1G  82% /
tmpfs           474M     0  474M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
/dev/vda1       511M  6.1M  505M   2% /boot/efi
tmpfs            95M  4.0K   95M   1% /run/user/0
overlay          23G   18G  4.1G  82% /var/lib/docker/overlay2/8a331589d7fa9046a6ef73489cc830c2583cb76c9174125c8bfe1064d58cd503/merged
overlay          23G   18G  4.1G  82% /var/lib/docker/overlay2/d56574358c8edbc9bc1fb50022585b854462a8ce56daa636b07f3a3771949251/merged

(¿Tres archivos de 18G en un servidor de 25G? Eso son 54G…)

Parece que algo es recuperable:

root@forum:/var/discourse# docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          2         2         4.3GB     3.334GB (77%)
Containers      2         2         1.849GB   0B (0%)
Local Volumes   0         0         0B        0B
Build Cache     0         0         0B        0B

…pero no estoy seguro de qué ni cómo.

El contenido de /var/discourse/shared/standalone/backups/default solo suma 67Mb.

Detuve docker con systemctl stop docker y probé esto sin éxito:

docker system prune -a
docker buildx prune --all
docker builder prune --all

…todos informaron 0B liberados.

Tengo dos imágenes de Docker, una para Discourse y otra para… “¿ninguna?”

root@forum:/var/discourse/image# docker images
REPOSITORY            TAG       IMAGE ID       CREATED        SIZE
local_discourse/app   latest    5ff1dcfe050c   2 months ago   4.09GB
<none>                <none>    bbaceb5f4a80   2 months ago   214MB

Aparentemente “” indica una imagen colgada o intermedia: Why the “none” image appears in Docker and how can we avoid it - Stack Overflow – pero es tan pequeña que no creo que sea mi principal prioridad.

Cuando los consejos en Is it safe to clean docker/overlay2/ - Stack Overflow entran en la búsqueda de overlays contra imágenes, pierdo el hilo. Hay 60 carpetas con hash en mi docker/overlay2… por favor, no me hagas buscar 120 veces…

Imagino que mis opciones en este punto son:
A. Obtener ayuda para averiguar si alguno de estos overlays se puede eliminar.
B. Restaurar desde una instantánea, actualizar para obtener más espacio en disco y volver a intentarlo. ¿Siempre tendré estos enormes overlays?

(¿Y cómo es que tengo 3 archivos de 18G en una instancia de 25G…?)

Si alguien está despierto a esta hora y tiene alguna idea, se lo agradecería.

Solo para repasar lo básico, pero ¿has intentado ./launcher cleanup y esto es lo que queda después?

3 Me gusta

Sí, la limpieza no tuvo ningún efecto.

2 Me gusta

No tienes dos archivos overlay de 18 GB, eso es una pista falsa. Docker usa overlayfs y esos son solo cómo tu disco existente se presenta al contenedor. /dev/vda2 es tu disco y está montado en / - ahí es donde deberías dirigir tus esfuerzos.

Si ./launcher cleanup no hizo nada, entonces asumo que docker image prune (elimina imágenes colgadas) tampoco lo hará. Si solo usas este servidor para discourse, puede que necesites revisar para asegurarte de que no haya archivos/carpetas grandes en tu directorio personal.

3 Me gusta

Vaya, eso es complicado por parte de Docker…
No, las operaciones de limpieza no recuperaron nada.
Estoy revisando /usr con ncdu… nada parece que no pertenezca obviamente, aunque no estoy seguro de qué hacer con /usr/lib/modules:

  547.2 MiB [###########################] /6.2.0-37-generic
  547.2 MiB [########################## ] /6.2.0-34-generic
    1.2 MiB [                           ] /6.2.0-33-generic
    1.2 MiB [                           ] /6.2.0-32-generic
    1.2 MiB [                           ] /6.2.0-35-generic
    1.2 MiB [                           ] /6.2.0-36-generic

Con mucho, el mayor uso se informa en las superposiciones en /var:

   16.0 GiB [###########################] /var
    4.3 GiB [#######                    ] /usr
    2.3 GiB [###                        ]  swapfile
    1.7 GiB [##                         ] /snap
  289.5 MiB [                           ] /boot

No hay nada en /snap más que lo que vino con él:

root@forum:/# snap list
Name    Version       Rev    Tracking         Publisher   Notes
core22  20230801      864    latest/stable    canonical✓  base
lxd     5.19-8635f82  26200  latest/stable/…  canonical✓  -
snapd   2.60.4        20290  latest/stable    canonical✓  snapd

¡Vaya, /var/log/journal se hizo grande!

    1.8 GiB [###########################] /7341e5ac94ae440bbd06f743e242da89
   16.0 MiB [                           ] /7025a9ae870140c1bef8e55211d339dc

Parece que han sido toneladas de bots intentando iniciar sesión en solo un par de meses.
Parece prudente conservar los registros por un tiempo, pero este foro todavía está en beta.
Quizás vaciar eso sea suficiente para que pueda volver a funcionar.

2 Me gusta

Bueno, eso no funcionó del todo, así que actualicé el servidor a 55G. Si esos grandes archivos de superposición son inevitables, supongo que realmente no había otra opción.

Se acaba de completar una actualización de Discourse, el sitio parece estar funcionando bien en 3.2.0.beta4-dev. :sweat_smile:

¡Gracias @JammyDodger y @Stephen por su atención y aportes!

3 Me gusta

Me estaba quedando sin espacio en un VPS Linode de 50 GB.

A continuación, se muestran algunos elementos que consumen espacio y que aún no se han mencionado. Algunos son específicos de Discourse y otros son generales para sistemas Linux.

  1. Ejecuta ll /lib/modules. Me sorprendió ver unos 15 GB de kernels antiguos que apt autoremove no se molestó en eliminar. Claude cree que se instalaron de forma no estándar y generó un script de eliminación seguro. Tardó aproximadamente una hora, pero funcionó (ejecútalo bajo tu propio riesgo, por supuesto) y pude ejecutar ./launcher rebuild sin el error no space left on device.

  2. El script no eliminó las cabeceras correspondientes en /usr/src. Para eso, ChatGPT creó otro script.

  3. Aproximadamente medio gigabyte de espacio fue ocupado por locales inútiles.

  4. Otro GB+ fue ocupado por el directorio /var/lib/docker/overlay2/.../merged/home/discourse/.cache.

Quizás sea una pregunta tonta, pero ¿qué contienen exactamente los directorios merge y diff? ¿Se puede eliminar alguno de ellos de forma segura en algún momento?

1 me gusta