Como resolver o erro 'cannot refresh cache whilst offline' no Linux e cPanel

Ao rodar consoles de administração (como Cockpit, PackageKit/pkcon) ou ferramentas de gerenciamento de pacotes (como dnf e yum) no terminal de um servidor Linux, você pode se deparar com a mensagem: Cannot refresh cache whilst offline.

Embora pareça apenas um aviso genérico de falta de internet, a falha geralmente decorre de um descompasso entre a expiração de metadados locais e a tentativa do binário de abrir conexões de rede com os mirrors remotos.

Abaixo, compartilho o comportamento por baixo do capô, as chamadas de sistema envolvidas, o roteiro de diagnóstico e as formas de resolver ou contornar o erro.

1. O que acontece por baixo do capô?#

O erro se manifesta quando o gerenciador de pacotes precisa atualizar metadados expirados, mas não consegue completar o handshake TCP com os repositórios.

A sequência de chamadas de sistema (syscalls) ilustra o fluxo:

1. socket(AF_INET, SOCK_STREAM, 0): O binário cria o socket TCP para consultar os mirrors.
2. connect(): O kernel tenta estabelecer a conexão. Se a rota padrão estiver indisponível ou o DNS falhar, o kernel retorna erros como EHOSTUNREACH ("No route to host") ou ETIMEDOUT.
3. openat() e fstat(): Paralelamente, o DNF lê os arquivos de metadados em /var/cache/dnf/. Se a diretiva metadata_expire tiver expirado, ele é forçado a tentar a atualização remota. Recebendo o erro de transporte, o utilitário aborta a execução com o aviso de offline.

2. Roteiro de diagnóstico via terminal#

Para isolar se o problema é de rede, DNS ou integridade de cache:

A. Validação de rota de saída e resolução de nomes#

# Checar gateway padrão
ip route show

# Validar resolução DNS
cat /etc/resolv.conf
getent hosts google.com

B. Rastreamento de chamadas com strace#

Para identificar onde o processo recebe a recusa:

strace -e trace=network,open,stat dnf makecache

Retornos rápidos de ECONNREFUSED ou EHOSTUNREACH logo após o connect() indicam problemas diretos de firewall ou tabela de rotas.

C. Inspeção de sockets ativos#

lsof -i -P -n | grep dnf

3. Formas de resolver e contornar o problema#

Dependendo da sua necessidade no momento, existem três abordagens práticas:

Método 1: Forçar a operação em modo offline (cache-only)#

Se o servidor estiver temporariamente sem acesso externo e você precisar apenas consultar ou instalar pacotes já baixados localmente:

# No DNF:
dnf -C list installed

# No YUM:
yum -C check-update

A flag -C (ou --cacheonly no DNF/YUM) instrui o gerenciador a ler estritamente a base local em /var/lib/dnf/ ou /var/cache/, ignorando qualquer tentativa de conexão com mirrors remotos.

Método 2: Limpeza e reconstrução de metadados#

Se a rede já estiver normalizada mas o banco SQLite do cache estiver inconsistente:

rm -rf /var/cache/dnf/*
dnf clean all
dnf makecache

Método 3: Ajuste de timeout e tempo de expiração do cache#

Para evitar que oscilações temporárias de rede causem falhas constantes, configure limites mais tolerantes no /etc/dnf/dnf.conf:

[main]
timeout=30
retries=3
metadata_expire=86400  # Mantém os metadados válidos por 24 horas

4. Casos de borda frequentes#

1. Proxy inativo em variáveis de ambiente: Se houver um proxy offline configurado em http_proxy ou https_proxy, o DNF falhará ao tentar conectar. Cheque com env | grep -i proxy.
2. Atributo imutável (chattr +i): Se diretórios de cache estiverem protegidos contra escrita por políticas de hardening, a atualização falha. Verifique com lsattr -d /var/cache/dnf.
3. Esgotamento de Inodes: Se a partição /var estiver com 100% de inodes ocupados, novos arquivos temporários de metadados não poderão ser criados. Valide com df -i.

5. Depuração com nível máximo de detalhes#

Para descobrir a URL exata do mirror que está falhando:

dnf -d 10 makecache

O nível de debug 10 imprime todos os cabeçalhos HTTP, rotas de mirrors e a pilha completa de exceções geradas pelo motor Python.

Lições práticas sobre o cache de pacotes#

1. Use -C (--cacheonly) para consultas rápidas: Quando a rede externa oscilar, a flag de cache local permite continuar operando sem bloqueios.
2. Entenda o ciclo de metadata_expire: Aumentar o tempo de expiração do cache reduz chamadas de rede desnecessárias em pipelines e scripts de rotina.
3. Valide a cadeia de rede antes de limpar caches: Muitas vezes o erro é apenas uma falha transitória de resolução DNS no /etc/resolv.conf.

Veja também

Linux Descompactação de arquivos .7z no Linux via CLI: do básico ao troubleshooting de baixo nível

Servidores Do 'no route to host' ao virtual host: debugging de Nginx standalone e redes na nuvem

Servidores Debugging de baixo nível no CloudLinux: syscalls, LVE e o perigo dos limites ilimitados

Este post está licenciado sob CC BY-NC.