Échec de la mise à jour : espace disque insuffisant -- fichiers overlay excessifs ?

Eh bien, soupir – je suis bloqué sur une mise à niveau échouée.

Je suis sur un VPS 25G, utilisant l’installation Docker prise en charge.

La mise à niveau de docker_manager via le panneau d’administration s’est bien déroulée.

La mise à niveau de Discourse de v3.2.0.beta1 +125 vers v3.2.0.beta3 +325 via le panneau d’administration a échoué, j’ai donc essayé une installation en ligne de commande :

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

…ce qui a également échoué :

Vous avez moins de 5 Go d'espace libre sur le disque où se trouve /var/lib/docker. Vous aurez besoin de plus d'espace pour continuer
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda2        23G   22G  640M  98% /

Apparemment à cause de deux fichiers “overlay” de 18 Go :

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

(Trois fichiers de 18 Go sur un serveur de 25 Go ? Cela fait 54 Go…)

Il semble que quelque chose soit récupérable :

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

…mais je ne suis pas sûr de quoi ni comment.

Le contenu de /var/discourse/shared/standalone/backups/default ne représente que 67 Mo.

J’ai arrêté docker avec systemctl stop docker et essayé ceci sans succès :

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

…tous ont signalé 0 octet libéré.

J’ai deux images Docker, une pour Discourse et une pour… “aucune ?”

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

Apparemment, “” indique une image orpheline ou intermédiaire : Why the “none” image appears in Docker and how can we avoid it - Stack Overflow – mais elle est si petite que je ne pense pas que ce soit ma priorité.

Quand les conseils de Is it safe to clean docker/overlay2/ - Stack Overflow entrent dans le filtrage des overlays par rapport aux images, je perds le fil. Il y a 60 dossiers hachés dans mon docker/overlay2… s’il vous plaît, ne me faites pas faire 120 greps…

J’imagine que mes options à ce stade sont :
A. Obtenir de l’aide pour déterminer si l’un de ces overlays peut être supprimé.
B. Restaurer à partir d’un instantané, mettre à niveau pour plus d’espace disque et réessayer. Aurai-je toujours ces énormes overlays ?

(Et comment ai-je 3 fichiers de 18 Go sur une instance de 25 Go… ?)

Si quelqu’un est réveillé à cette heure et a une idée, je l’apprécierais.

Juste pour vérifier les bases, mais avez-vous essayé ./launcher cleanup et est-ce ce qu’il reste après ?

3 « J'aime »

Oui - le nettoyage n’a eu aucun effet.

2 « J'aime »

Vous n’avez pas deux fichiers overlay de 18 Go, c’est une fausse piste. Docker utilise overlayfs et ce ne sont que des représentations de votre disque existant pour le conteneur. /dev/vda2 est votre disque et est monté sur / - c’est là que vous devriez concentrer vos efforts.

Si ./launcher cleanup n’a rien fait, alors je suppose que docker image prune (supprime les images orphelines) ne fera rien non plus. Si vous n’utilisez ce serveur que pour discourse, vous devrez peut-être simplement vérifier qu’il n’y a pas de gros fichiers/dossiers dans votre répertoire personnel.

3 « J'aime »

Ohh – eh bien, c’est délicat de la part de Docker…
Non, les opérations de nettoyage n’ont rien récupéré.
J’examine /usr avec ncdu… rien ne semble évidemment déplacé, bien que je ne sache pas quoi penser de /usr/lib/modules :

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

De loin, l’utilisation la plus importante est signalée par les superpositions dans /var :

   16.0 Gio [###########################] /var
    4.3 Gio [#######                    ] /usr
    2.3 Gio [###                        ]  swapfile
    1.7 Gio [##                         ] /snap
  289.5 Mio [                           ] /boot

Il n’y a rien dans /snap à part ce qui est venu avec :

root@forum:/# snap list
Nom    Version       Rev    Suivi           Éditeur      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 est devenu énorme !

    1.8 Gio [###########################] /7341e5ac94ae440bbd06f743e242da89
   16.0 Mio [                           ] /7025a9ae870140c1bef8e55211d339dc

On dirait que des tonnes de bots ont essayé de se connecter en quelques mois seulement.
Il semble prudent de conserver les journaux pendant un certain temps, mais ce forum est encore en version bêta.
Peut-être que le nettoyage de cela suffira à me relancer.

2 « J'aime »

Eh bien, cela n’a pas tout à fait fonctionné, j’ai donc mis à niveau le serveur vers 55G. Si ces gros fichiers de superposition sont inévitables, je suppose qu’il n’y avait pas vraiment d’autre choix.

Une mise à niveau de Discourse vient de se terminer, le site semble fonctionner correctement sur la version 3.2.0.beta4-dev. :sweat_smile:

Merci @JammyDodger et @Stephen pour votre attention et vos commentaires !

3 « J'aime »

Je manquais d’espace sur un VPS Linode de 50 Go.

Voici quelques éléments qui consomment de l’espace et qui n’ont pas encore été mentionnés. Certains sont spécifiques à Discourse, d’autres sont généraux aux systèmes Linux.

  1. Exécutez ll /lib/modules. J’ai été surpris de voir environ 15 Go de vieux noyaux que apt autoremove n’a pas pris la peine de supprimer. Claude pense qu’ils ont été installés d’une manière non standard et a généré un script de suppression sûr. Cela a pris environ une heure mais cela a fonctionné (exécutez à vos propres risques, bien sûr) et j’ai pu exécuter ./launcher rebuild sans l’erreur no space left on device.

  2. Le script n’a pas supprimé les en-têtes correspondants dans /usr/src. Pour cela, ChatGPT a créé un autre script.

  3. Environ un demi-gigaoctet d’espace a été occupé par des locales inutiles.

  4. Encore 1 Go+ a été occupé par le répertoire /var/lib/docker/overlay2/.../merged/home/discourse/.cache.

Peut-être une question stupide, mais que contiennent exactement les répertoires merge et diff ? Peut-on en supprimer un en toute sécurité à un moment donné ?

1 « J'aime »