Se você usa Ubuntu há algum tempo, provavelmente já notou que o diretório /var/lib/snapd cresce de forma silenciosa e constante. O motivo não são os pacotes Snap que você instalou — são as cópias antigas que o sistema guarda automaticamente toda vez que um desses pacotes recebe atualização. Em uma instalação com dezenas de snaps, é comum encontrar 5, 8 ou até mais gigabytes ocupados por revisões que você nunca vai usar. O problema é especialmente incômodo em partições menores, SSDs com espaço limitado ou VMs com disco enxuto. A boa notícia é que identificar e remover esse excesso leva poucos minutos, desde que você saiba onde olhar e o que não apagar.

O que são revisões do Snap e por que elas existem#

O snapd trabalha com um conceito de revisões imutáveis. Cada vez que um snap recebe uma atualização, a versão anterior não é apagada — ela é marcada como disabled e permanece no disco, intacta, pronta para ser reativada caso a versão nova apresente problemas. Isso significa que o sistema sempre mantém pelo menos duas cópias de cada snap instalado: a ativa e a anterior. O mecanismo é análogo ao que distribuições como o NixOS e o Fedora Silverblue fazem com o sistema inteiro, mas aplicado no nível de cada pacote individual.

Esse comportamento é controlado pela configuração refresh.retain, que define quantas revisões o snapd deve manter por snap. O valor padrão é 2, e esse também é o valor mínimo — não é possível configurar o sistema para manter apenas a versão ativa sem nenhum backup. A Canonical impõe esse piso porque o rollback é uma das garantias fundamentais da arquitetura Snap, e permitir que o usuário eliminasse toda redundância comprometeria essa promessa.

O cenário onde isso faz mais sentido é o de dispositivos IoT, edge computing e infraestrutura industrial. Nesses ambientes, os snaps são atualizados remotamente e de forma autônoma, e a capacidade de reverter para a versão anterior sem intervenção humana no local é parte do apelo comercial da plataforma. Se um gateway de borda em uma fábrica recebe uma atualização defeituosa às 3 da manhã, o rollback automático resolve o problema antes que alguém precise sair da cama. No seu desktop ou laptop, porém, a utilidade prática desse seguro é bem menor — e o custo em disco pode ser difícil de justificar quando o espaço está curto.

Diagnóstico: quanto espaço está sendo consumido#

Antes de sair removendo revisões, vale entender o tamanho do problema na sua instalação específica. A quantidade de espaço desperdiçado varia bastante dependendo de quantos snaps você tem instalados e com que frequência eles são atualizados — um sistema com meia dúzia de snaps leves pode estar perdendo apenas algumas centenas de megabytes, enquanto um com Firefox, Chromium, LibreOffice e vários runtimes GNOME pode facilmente ultrapassar os 5 GB de revisões desativadas.

Listando todas as revisões#

O ponto de partida é o comando snap list --all, que mostra todos os snaps instalados junto com suas revisões, incluindo as desativadas:

sudo snap list --all

A saída inclui colunas como nome, versão, número da revisão e notas. A informação que interessa aqui é a coluna “Notes” — revisões antigas aparecem marcadas como disabled. Cada linha com essa marcação representa uma cópia inativa ocupando espaço no disco. Se você quiser uma visão mais limpa, filtrando apenas as revisões desativadas:

snap list --all | grep disabled

O número de linhas na saída desse comando já dá uma ideia da escala do problema. Cada uma delas é um candidato à remoção.

Medindo o consumo real#

O comando snap list não mostra o tamanho de cada revisão, então para ter uma noção do impacto real em disco você precisa olhar diretamente no filesystem. O caminho mais rápido é:

sudo du -sh /var/lib/snapd

Esse valor inclui tudo que o snapd gerencia — revisões ativas, desativadas, caches e metadados. Para um detalhamento por snap individual, navegue até o diretório onde os arquivos .snap ficam armazenados:

sudo du -sh /var/lib/snapd/snaps/*

Cada arquivo nesse diretório corresponde a uma revisão específica (o nome segue o padrão nome_revisão.snap), e você consegue cruzar os números de revisão com a saída do snap list --all para saber quais são ativos e quais são os candidatos à limpeza. Se preferir uma visão gráfica, o Disk Usage Analyser (Analisador de Uso de Disco) do GNOME permite navegar até /var/lib/snapd/snaps e ver rapidamente quais arquivos são maiores e mais antigos — a combinação de tamanho e data ajuda a tomar decisões com mais confiança sobre o que remover.

Limpeza manual: removendo revisões uma a uma#

A abordagem mais segura para limpar revisões desativadas é removê-las individualmente, conferindo cada uma antes de executar o comando. O processo é simples mas exige atenção — o snap remove com a flag --revision não pede confirmação antes de agir.

O comando segue este formato:

sudo snap remove --revision=NÚMERO nome-do-snap

Por exemplo, se o snap list --all mostra que o Firefox tem a revisão 5678 marcada como disabled, o comando seria:

sudo snap remove --revision=5678 firefox

A remoção é imediata e silenciosa. Se o número da revisão ou o nome do snap estiver errado, o comando falha sem causar dano — mas se você acidentalmente informar a revisão ativa, o snapd se recusa a removê-la, então não há risco de quebrar um snap em uso por engano.

O fluxo de trabalho que funciona melhor na prática é manter dois terminais lado a lado: um com a saída do snap list --all | grep disabled visível para consulta, e outro onde você digita os comandos de remoção. Isso evita erros de digitação nos números de revisão e permite que você vá riscando mentalmente as linhas já processadas. Em uma instalação com poucos snaps desativados, o processo inteiro leva menos de dois minutos.

A vantagem dessa abordagem sobre um script automatizado é o controle granular. Você pode decidir, por exemplo, manter a revisão anterior do snapd ou do core22 como precaução extra enquanto remove sem peso na consciência as revisões antigas do snap-store ou do gtk-common-themes. Nem todo snap tem o mesmo nível de criticidade, e a remoção manual permite que você faça essa triagem caso a caso.

Limpeza rápida: o one-liner para remover tudo de uma vez#

Se você já entende o que está sendo removido e não precisa avaliar cada snap individualmente, um loop em uma linha resolve o trabalho inteiro de uma vez. Essa é a abordagem que a maioria dos tutoriais na internet recomenda, e ela funciona bem — desde que você saiba o que está fazendo.

O loop em uma linha#

O comando combina snap list --all com filtros de texto para extrair os nomes e revisões de todos os snaps desativados e passá-los diretamente ao snap remove:

snap list --all \
    | awk '/disabled/{print $1, $3}' \
    | while read name rev; do
        sudo snap remove "$name" --revision="$rev"
    done

O awk filtra as linhas que contêm “disabled” e extrai o primeiro campo (nome do snap) e o terceiro (número da revisão). O while read itera sobre cada par e executa a remoção. O processo leva de alguns segundos a pouco mais de um minuto dependendo da quantidade de revisões acumuladas, e a saída do terminal vai mostrando cada snap removido conforme o loop avança.

Variação com dry-run#

O snap remove não tem uma flag de dry-run nativa, mas é fácil simular uma substituindo a execução por um echo:

snap list --all \
    | awk '/disabled/{print $1, $3}' \
    | while read name rev; do
        echo "snap remove $name --revision=$rev"
    done

A saída mostra exatamente quais comandos seriam executados, sem tocar em nada. Isso permite revisar a lista completa antes de comprometer qualquer mudança. Se tudo parecer correto, basta rodar a versão real. Se algum snap específico aparecer na lista e você preferir preservá-lo — como o snapd ou um kernel snap — anote o nome e adicione um filtro extra ao awk, por exemplo:

snap list --all \
    | awk '/disabled/ && !/snapd/ && !/core/{print $1, $3}' \
    | while read name rev; do
        sudo snap remove "$name" --revision="$rev"
    done

Essa variação exclui da remoção qualquer linha que contenha “snapd” ou “core”, preservando as revisões de backup dos componentes mais sensíveis do sistema enquanto limpa todo o resto.

Riscos e cuidados#

Remover revisões desativadas do Snap não é uma operação destrutiva no sentido clássico — você não está apagando dados pessoais nem desinstalando programas. Mas também não é uma ação sem consequências, e vale entender o que você está abrindo mão antes de sair limpando tudo.

Sem rollback disponível#

O efeito mais direto da remoção é a perda da capacidade de rollback. Se a versão ativa de um snap apresentar um bug após a próxima atualização, o snapd não terá uma revisão anterior para a qual reverter — o comando snap revert nome-do-snap vai falhar porque não existe mais uma cópia de backup no disco. Na prática, isso significa que sua única opção diante de uma atualização problemática será esperar por uma correção upstream ou reinstalar o snap por completo, perdendo eventuais configurações locais que não estejam salvas em outro lugar.

Para a maioria dos snaps de desktop — editores de texto, clientes de mensagem, utilitários diversos — esse risco é baixo. Atualizações problemáticas nesses pacotes costumam ser mais irritantes do que incapacitantes, e uma correção geralmente aparece em poucos dias. O cenário muda quando se trata de snaps que afetam o funcionamento básico do sistema.

Snaps de sistema e kernel#

Os snaps snapd, core, core20, core22, core24 e eventuais kernel snaps formam a base sobre a qual todos os outros snaps executam. Uma atualização defeituosa em qualquer um deles pode impedir que outros snaps iniciem ou, em casos mais graves, afetar o processo de boot em sistemas que dependem de snaps para componentes de inicialização. Remover a revisão de backup desses pacotes elimina a rede de segurança justamente onde ela é mais necessária.

A recomendação é simples: se for usar o one-liner para limpeza em massa, exclua esses snaps do filtro (como mostrado na variação com !/snapd/ && !/core/ na seção anterior). Se for fazer a remoção manual, pule as linhas correspondentes a esses pacotes. O espaço que eles ocupam raramente justifica o risco.

Isso não é permanente#

A limpeza de revisões desativadas resolve o problema de espaço no momento em que é feita, mas não altera o comportamento do snapd dali em diante. Na próxima vez que qualquer snap instalado receber uma atualização, a versão atual será retida como backup e o ciclo recomeça. Dependendo de quantos snaps você tem e da frequência com que eles são atualizados, o acúmulo pode voltar a níveis incômodos em algumas semanas ou poucos meses.

Não existe uma forma nativa de desabilitar a retenção de revisões ou de agendar a limpeza automática. Se o espaço em disco for uma preocupação recorrente no seu sistema, essa remoção vai se tornar uma tarefa periódica — algo para incluir na sua rotina de manutenção junto com apt autoremove e limpeza de cache do journalctl. Se quiser automatizar essa limpeza, vale considerar os systemd timers em vez do cron — ou o launchd se estiver no macOS.

Alternativa: ajustando o refresh.retain#

Antes de recorrer à remoção manual ou ao one-liner, vale verificar se o seu sistema já está configurado para reter o mínimo de revisões possível. A configuração refresh.retain do snapd define quantas revisões de cada snap são mantidas no disco, e o valor padrão em instalações mais antigas pode estar em 3 — o que significa que o sistema guarda duas cópias de backup em vez de uma.

Para consultar o valor atual:

sudo snap get system refresh.retain

Se a saída mostrar um número maior que 2, você pode reduzi-lo ao mínimo com:

sudo snap set system refresh.retain=2

A mudança é imediata e afeta o comportamento de todas as atualizações futuras. A partir desse ponto, o snapd passa a manter no máximo uma revisão de backup por snap, descartando automaticamente a mais antiga sempre que uma nova atualização chegar. Revisões excedentes que já existem no disco não são removidas retroativamente — para limpar o que já acumulou, você ainda precisa usar os comandos das seções anteriores.

O valor 2 é o piso absoluto dessa configuração. Tentar definir refresh.retain=1 resulta em erro, porque a Canonical considera a existência de pelo menos um backup como requisito inegociável da arquitetura Snap. Não existe flag oculta, variável de ambiente ou workaround documentado para contornar essa limitação. Se manter uma única cópia de cada snap (sem backup nenhum) é o que você realmente precisa, a única forma de chegar lá é removendo as revisões desativadas manualmente após cada ciclo de atualização — o que nos traz de volta aos comandos já cobertos neste post.