Aggiornamento fallito: spazio su disco insufficiente -- troppi file overlay?

Beh, sospiro – sono bloccato su un aggiornamento fallito.

Sono su un VPS da 25G, utilizzando l’installazione Docker supportata.

L’aggiornamento di docker_manager tramite il pannello di amministrazione è andato bene.

L’aggiornamento di Discourse da v3.2.0.beta1 +125 a v3.2.0.beta3 +325 tramite il pannello di amministrazione è fallito, quindi ho provato un’installazione da riga di comando:

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

…che è fallito anche questo:

Hai meno di 5 GB di spazio libero sul disco in cui si trova /var/lib/docker. Avrai bisogno di più spazio per continuare
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda2        23G   22G  640M  98% /

Apparentemente a causa di due file “overlay” da 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

(Tre file da 18G su un server da 25G? Sono 54G…)

Sembra che qualcosa sia recuperabile:

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

…ma non sono sicuro di cosa o come.

Il contenuto di /var/discourse/shared/standalone/backups/default ammonta solo a 67 MB.

Ho fermato docker con systemctl stop docker e ho provato quanto segue senza successo:

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

…tutti hanno riportato 0B liberati.

Ho due immagini Docker, una per Discourse e una per… “nessuna?”

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

Apparentemente “nessuna” indica un’immagine dangling o intermedia: Why the “none” image appears in Docker and how can we avoid it - Stack Overflow – ma è così piccola che non penso sia la mia prima priorità.

Quando i consigli su Is it safe to clean docker/overlay2/ - Stack Overflow entrano nel grep degli overlay contro le immagini, perdo il filo. Ci sono 60 cartelle con hash nel mio docker/overlay2… per favore, non farmi fare 120 grep…

Immagino che le mie opzioni a questo punto siano:
A. Chiedere aiuto per capire se uno qualsiasi di questi overlay può essere eliminato.
B. Ripristinare da uno snapshot, aggiornare per più spazio su disco e riprovare. Avrò sempre questi enormi overlay?

(E come faccio ad avere 3 file da 18G su un’istanza da 25G..?)

Se qualcuno è sveglio a quest’ora e ha qualche suggerimento, lo apprezzerei.

Solo per spuntare le basi, ma hai provato ./launcher cleanup e questo è ciò che è rimasto dopo?

3 Mi Piace

Sì, la pulizia non ha avuto effetto.

2 Mi Piace

Non hai due file overlay da 18 GB, è un depistaggio. Docker usa overlayfs e quelli sono solo il modo in cui il tuo disco esistente viene presentato al container. /dev/vda2 è il tuo disco ed è montato su / - è lì che dovresti concentrare i tuoi sforzi.

Se ./launcher cleanup non ha fatto nulla, presumo che anche docker image prune (rimuove le immagini pendenti) non farà nulla. Se stai usando questo server solo per discourse, potresti dover semplicemente controllare che non ci siano file/cartelle di grandi dimensioni nella tua directory home.

3 Mi Piace

Ohh – beh, questo è complicato da Docker…
No, le operazioni di pulizia non hanno recuperato nulla.
Sto esaminando /usr con ncdu… niente sembra fuori posto, anche se non sono sicuro di cosa pensare di /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

Di gran lunga l’uso maggiore è riportato negli overlay in /var:

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

Non c’è niente in /snap se non ciò che è stato fornito:

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

Whoa – /var/log/journal è diventato grande!

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

Sembra che siano stati tantissimi bot a tentare di accedere negli ultimi due mesi.
Sembra prudente conservare i log per un po’, ma questo forum è ancora in beta.
Forse il vacuuming di quello sarà sufficiente per farmi ripartire.

2 Mi Piace

Beh, non ha funzionato del tutto, quindi ho aggiornato il server a 55G. Se quei grandi file di sovrapposizione sono inevitabili, immagino che non ci fosse davvero altra scelta.

Un aggiornamento di Discourse è appena stato completato, il sito sembra funzionare bene sulla versione 3.2.0.beta4-dev. :sweat_smile:

Grazie @JammyDodger e @Stephen per la vostra attenzione e il vostro contributo!

3 Mi Piace

Stavo esaurendo lo spazio su un VPS Linode da 50 GB.

Di seguito sono riportati alcuni “divoratori” di spazio che non sono ancora stati menzionati. Alcuni sono specifici di Discourse, altri sono generali per i sistemi Linux.

  1. Esegui ll /lib/modules. Sono rimasto sorpreso nel vedere circa 15 GB di vecchi kernel che apt autoremove non si è preoccupato di rimuovere. Claude pensa che siano stati installati in modo non standard e ha generato uno script sicuro di rimozione. Ci è voluta circa un’ora ma ha funzionato (eseguilo a tuo rischio, ovviamente) e sono stato in grado di eseguire ./launcher rebuild senza l’errore no space left on device.

  2. Lo script non ha eliminato gli header corrispondenti in /usr/src. Per questo ChatGPT ha creato un altro script.

  3. Circa mezzo gigabyte di spazio è stato occupato da locales inutili.

  4. Un altro GB+ è stato occupato dalla directory /var/lib/docker/overlay2/.../merged/home/discourse/.cache.

Forse una domanda stupida, ma cosa contengono esattamente le directory merge e diff? Si può eliminare in sicurezza una di esse in qualche momento?

1 Mi Piace