Upgrade fehlgeschlagen: zu wenig Speicherplatz – zu viele Overlay-Dateien?

Nun, seufz – ich stecke bei einem fehlgeschlagenen Upgrade fest.

Ich habe einen 25G VPS mit der unterstützten Docker-Installation.

Das Upgrade von docker_manager über das Admin-Panel verlief problemlos.

Das Upgrade von Discourse von v3.2.0.beta1 +125 auf v3.2.0.beta3 +325 über das Admin-Panel schlug fehl, also versuchte ich eine Installation über die Kommandozeile:

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

…was ebenfalls fehlschlug:

Sie haben weniger als 5 GB freien Speicherplatz auf der Festplatte, auf der sich /var/lib/docker befindet. Sie benötigen mehr Speicherplatz, um fortzufahren
Dateisystem      Größe  Benutzt Verf. Verw% Eingehängt auf
/dev/vda2        23G   22G   640M  98% /

Anscheinend wegen zweier 18G “overlay”-Dateien:

root@forum:/var/discourse# df -h
Dateisystem      Größe  Benutzt Verf. Verw% Eingehängt auf
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

(Drei 18G-Dateien auf einem 25G-Server? Das sind 54G…)

Es scheint, etwas ist wiederherstellbar:

root@forum:/var/discourse# docker system df
TYP           GESAMT   AKTIV    GRÖSSE     WIEDERHERSTELLBAR
Images          2         2         4,3GB     3,334GB (77%)
Container       2         2         1,849GB   0B (0%)
Lokale Volumes  0         0         0B        0B
Build Cache     0         0         0B        0B

…aber ich bin mir nicht sicher, was oder wie.

Der Inhalt von /var/discourse/shared/standalone/backups/default beträgt nur 67 MB.

Ich habe Docker mit systemctl stop docker gestoppt und Folgendes ohne Erfolg versucht:

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

…alle meldeten 0B freigegeben.

Ich habe zwei Docker-Images, eines für Discourse und eines für… “none?”

root@forum:/var/discourse/image# docker images
REPOSITORY            TAG       IMAGE ID       ERSTELLT     GRÖSSE
local_discourse/app   latest    5ff1dcfe050c   2 Monate her   4,09GB
<none>                <none>    bbaceb5f4a80   2 Monate her   214MB

Anscheinend bedeutet “none” ein hängendes oder zwischenzeitliches Image: Why the “none” image appears in Docker and how can we avoid it - Stack Overflow – aber es ist so klein, dass ich nicht denke, dass es meine erste Priorität ist.

Wenn die Ratschläge bei Is it safe to clean docker/overlay2/ - Stack Overflow das Greppen von Overlays gegen Images beinhalten, verliere ich den Faden. Es gibt 60 gehashte Ordner in meinem docker/overlay2… bitte lassen Sie mich nicht 120 Mal greppen…

Ich stelle mir meine Optionen zu diesem Zeitpunkt wie folgt vor:
A. Holen Sie sich Hilfe, um herauszufinden, ob eines dieser Overlays gelöscht werden kann.
B. Stellen Sie aus einem Snapshot wieder her, führen Sie ein Upgrade für mehr Speicherplatz durch und versuchen Sie es erneut. Werden diese riesigen Overlays immer vorhanden sein?

(Und wie habe ich überhaupt 3 x 18G-Dateien auf einer 25G-Instanz..?)

Wenn jemand zu dieser Stunde wach ist und einen Beitrag leisten kann, würde ich mich freuen.

Nur um die Grundlagen abzuhaken, aber Sie haben ./launcher cleanup versucht und das ist übrig geblieben?

3 „Gefällt mir“

Ja – die Bereinigung hatte keine Auswirkung.

2 „Gefällt mir“

Sie haben keine zwei 18 GB großen Overlay-Dateien, das ist eine falsche Fährte. Docker verwendet overlayfs und das sind nur die Möglichkeiten, wie Ihre vorhandene Festplatte dem Container präsentiert wird. /dev/vda2 ist Ihre Festplatte und ist unter / gemountet – dort sollten Sie Ihre Bemühungen richten.

Wenn ./launcher cleanup nichts gebracht hat, gehe ich davon aus, dass docker image prune (entfernt hängende Images) auch nichts bringen wird. Wenn Sie diesen Server nur für Discourse verwenden, müssen Sie möglicherweise nur prüfen, ob sich keine großen Dateien/Ordner in Ihrem Home-Verzeichnis befinden.

3 „Gefällt mir“

Ach, das ist ja knifflig von Docker…
Nein, die Bereinigungsoperationen haben nichts wiederhergestellt.
Ich durchforste jetzt /usr mit ncdu… nichts sieht so aus, als ob es offensichtlich nicht hingehört, obwohl ich nicht sicher bin, was ich von /usr/lib/modules halten soll:

  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

Bei weitem die meiste Nutzung wird von den Overlays in /var gemeldet:

   16,0 GiB [###########################] /var
    4,3 GiB [#######                    ] /usr
    2,3 GiB [###                        ]  swapfile
    1,7 GiB [##                         ] /snap
  289,5 MiB [                           ] /boot

In /snap ist nichts außer dem, was es mitgebracht hat:

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

Wow – /var/log/journal ist groß geworden!

    1,8 GiB [###########################] /7341e5ac94ae440bbd06f743e242da89
   16,0 MiB [                           ] /7025a9ae870140c1bef8e55211d339dc

Sieht so aus, als ob in nur wenigen Monaten tonnenweise Bots versucht haben, sich anzumelden.
Es scheint ratsam zu sein, die Protokolle eine Weile aufzubewahren, aber dieses Forum ist noch Beta.
Vielleicht reicht es, das zu leeren, damit ich wieder loslegen kann.

2 „Gefällt mir“

Nun, das hat nicht ganz funktioniert, also habe ich den Server auf 55G aufgerüstet. Wenn diese großen Overlay-Dateien unvermeidlich sind, gab es wohl keine wirkliche Wahl.

Ein Discourse-Upgrade wurde gerade abgeschlossen, die Seite scheint unter 3.2.0.beta4-dev einwandfrei zu funktionieren. :sweat_smile:

Vielen Dank an @JammyDodger und @Stephen für Ihre Aufmerksamkeit und Ihren Beitrag!

3 „Gefällt mir“

Ich ging der Speicherplatz auf einem 50 GB Linode VPS aus.

Unten sind einige Speicherplatzfresser, die noch nicht erwähnt wurden. Einige sind Discourse-spezifisch, einige sind allgemein für Linux-Systeme.

  1. Führen Sie ll /lib/modules aus. Ich war überrascht, etwa 15 GB alte Kernel zu sehen, die apt autoremove nicht entfernen wollte. Claude glaubt, dass sie auf eine nicht standardmäßige Weise installiert wurden und hat ein sicheres Entfernungsskript erstellt. Es dauerte etwa eine Stunde, aber es funktionierte (auf eigene Gefahr natürlich) und ich konnte ./launcher rebuild ohne die Fehlermeldung no space left on device ausführen.

  2. Das Skript hat nicht die entsprechenden Header in /usr/src gelöscht. Dafür hat ChatGPT ein weiteres Skript erstellt.

  3. Etwa ein halbes Gigabyte Speicherplatz wurde von nutzlosen Locales belegt.

  4. Weitere 1 GB+ wurden vom Verzeichnis /var/lib/docker/overlay2/.../merged/home/discourse/.cache belegt.

Vielleicht eine dumme Frage, aber was genau enthalten die Verzeichnisse merge und diff? Kann eines davon sicher irgendwann gelöscht werden?

1 „Gefällt mir“