Falha na atualização: espaço em disco insuficiente -- arquivos de overlay excessivos?

Bem, suspiro – estou preso em uma atualização falha.

Estou em um VPS de 25G, usando a instalação Docker suportada.

A atualização do docker_manager através do painel de administração correu bem.

A atualização do Discourse de v3.2.0.beta1 +125 para v3.2.0.beta3 +325 através do painel de administração falhou, então tentei uma instalação pela linha de comando:

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

…o que também falhou:

Você tem menos de 5 GB de espaço livre no disco onde /var/lib/docker está localizado. Você precisará de mais espaço para continuar
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda2        23G   22G  640M  98% /

Aparentemente por causa de dois arquivos “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

(Três arquivos de 18G em um servidor de 25G? Isso dá 54G…)

Parece que algo é recuperável:

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

…mas não tenho certeza do quê ou como.

O conteúdo de /var/discourse/shared/standalone/backups/default totaliza apenas 67Mb.

Parei o docker com systemctl stop docker e tentei o seguinte sem sucesso:

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

…todos relataram 0B liberados.

Tenho duas imagens Docker, uma para Discourse e outra para… “none?”

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 “none” indica uma imagem pendente ou intermediária: Why the “none” image appears in Docker and how can we avoid it - Stack Overflow – mas é tão pequena que não acho que seja minha primeira prioridade.

Quando os conselhos em Is it safe to clean docker/overlay2/ - Stack Overflow entram em grepping de overlays contra imagens, eu perco o fôlego. Existem 60 pastas com hash em meu docker/overlay2… por favor, não me faça grepar 120 vezes…

Imagino que minhas opções neste ponto sejam:
A. Obter ajuda para descobrir se algum desses overlays pode ser excluído.
B. Restaurar de um snapshot, atualizar para mais espaço em disco e tentar novamente. Terei sempre esses overlays enormes?

(E como eu tenho 3 arquivos de 18G em uma instância de 25G..?)

Se alguém estiver acordado a esta hora e tiver alguma contribuição, eu agradeceria.

Só para verificar o básico, mas você tentou ./launcher cleanup e é isso que sobrou depois?

3 curtidas

Sim - a limpeza não teve efeito.

2 curtidas

Você não tem dois arquivos overlay de 18GB, isso é uma pista falsa. O Docker usa overlayfs e esses são apenas a forma como seu disco existente é apresentado ao contêiner. /dev/vda2 é o seu disco e está montado em / - é aí que você deve direcionar seus esforços.

Se ./launcher cleanup não fez nada, então presumo que docker image prune (remove imagens pendentes) também não fará. Se você está usando este servidor apenas para discourse, pode ser necessário verificar se não há arquivos/pastas grandes em seu diretório home.

3 curtidas

Ohh – bem, isso é complicado do Docker…
Não, as operações de limpeza não recuperaram nada.
Estou vasculhando /usr com o ncdu… nada parece que obviamente não pertence, embora eu não tenha certeza do que fazer com /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

De longe, o maior uso é relatado como os overlays em /var:

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

Não há nada em /snap além do que veio com ele:

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

Uau – /var/log/journal ficou grande!

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

Parece que foram muitos bots tentando fazer login em apenas alguns meses.
Parece prudente reter os logs por um tempo, mas este fórum ainda está em beta.
Talvez fazer o vacuum disso seja o suficiente para eu voltar a funcionar.

2 curtidas

Bem, isso não resolveu completamente, então atualizei o servidor para 55G. Se esses grandes arquivos de sobreposição forem inevitáveis, acho que não havia realmente escolha.

Uma atualização do Discourse foi concluída, o site parece estar funcionando bem na 3.2.0.beta4-dev. :sweat_smile:

Obrigado @JammyDodger e @Stephen pela sua atenção e contribuições!

3 curtidas

Estava ficando sem espaço em um VPS Linode de 50GB.

Abaixo estão alguns “ladrões” de espaço que ainda não foram mencionados. Alguns são específicos do Discourse, outros são gerais para sistemas Linux.

  1. Execute ll /lib/modules. Fiquei surpreso ao ver cerca de 15GB de kernels antigos que apt autoremove não removeu. Claude acha que eles foram instalados de forma não padrão e gerou um script de remoção seguro. Levou cerca de uma hora, mas funcionou (execute por sua conta e risco, é claro) e consegui executar ./launcher rebuild sem o erro no space left on device.

  2. O script não excluiu os cabeçalhos correspondentes em /usr/src. Para isso, o ChatGPT criou outro script.

  3. Cerca de meio gigabyte de espaço foi ocupado por locales inúteis.

  4. Mais 1GB+ foi ocupado pelo diretório /var/lib/docker/overlay2/.../merged/home/discourse/.cache.

Talvez uma pergunta estúpida, mas o que exatamente os diretórios merge e diff contêm? Algum deles pode ser excluído com segurança em algum momento?

1 curtida