Troubleshooting Artix Linux + Docker + Git - Sessão Completa
Prologo - Por que Artix
A parte 1 - Inicio da odisseia
A parte 2 - Tentando se manter no terminal
A parte 3 - Deixando mais palatável
1. ZRAM - "não entra nada lá nunca"
swapon --show zramctl lsmod | grep zram
Resultado
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT /dev/zram0 zstd 12G 4K 59B 20K [SWAP]
À primeira vista parece estranho:
“Configurei 12 GB de swap e não tem nada sendo usado?”
Na prática, isso está exatamente correto.
O que esses números realmente significam
- /dev/zram0 → dispositivo de swap em memória (não é disco)
- ALGORITHM: zstd → algoritmo de compressão usado
- DISKSIZE: 12G → tamanho lógico disponível
- DATA: 4K → dados antes da compressão
- COMPR: 59B → tamanho após compressão
- TOTAL: 20K → uso real de memória (incluindo overhead)
Ou seja: praticamente zero uso real.
Como o ZRAM funciona de verdade
ZRAM não é swap tradicional.
Ele cria um “disco” dentro da RAM, mas com compressão:
Memória começa a encher
↓
Kernel decide usar swap
↓
Ao invés de ir pro SSD
↓
Vai pro ZRAM
↓
Dados são comprimidos
↓
E continuam na própria RAM (só que comprimidos)Por que não está sendo usado
Seu cenário:
- 32 GB de RAM
- ~11 GB em uso
- ~19 GB livres
O kernel simplesmente não precisa usar swap.
E Linux moderno trata swap assim:
último recurso, não extensão de memória
AlgoritmoCompressãoCPULatência
lzo | baixa | muito baixo | muito baixa lz4 | média | baixo | muito baixa zstd | alta | moderado | baixa
Por que zstd é a melhor escolha aqui
O zstd entrega:
- compressão maior → mais “RAM efetiva”
- descompressão muito rápida
- bom uso de múltiplos cores
2. Timeshift - Backup automático no Artix com OpenRC
Hook do pacman (backup antes de instalar/atualizar/remover pacotes)
sudo mkdir -p /etc/pacman.d/hooks sudo nano /etc/pacman.d/hooks/timeshift-backup.hook
Conteúdo:
[Trigger] Operation = Install Operation = Upgrade Operation = Remove Type = Package Target = * [Action] Description = Timeshift backup antes de modificar pacotes... When = PreTransaction Exec = /usr/bin/timeshift --create --comments "pacman hook" --tags D AbortOnFail
Backup diário com cronie
sudo pacman -S cronie sudo rc-update add cronie default sudo rc-service cronie start sudo crontab -e
Adicionar:
0 3 * * * /usr/bin/timeshift --create --comments "backup diário" --tags D
Alternativa: usar o GUI do Timeshift
O Timeshift GUI (Settings → Schedule) configura o cron automaticamente. O arquivo gerado fica em /etc/cron.d/timeshift-boot com um sleep 10m para não impactar o boot.
O GUI não configura o hook do pacman, esse precisa ser criado manualmente.
3. Docker parou após yay -Syu
Sintoma
failed to connect to the docker API at unix:///var/run/docker.sock
Causa
O containerd ficou com processo zumbi após o update. O log mostrou que o Docker foi encerrado normalmente com Processing signal 'terminated' mas o containerd não subiu corretamente.
Além disso, o kernel havia sido atualizado mas ainda não estava em uso (uname -r diferente do vmlinuz em /boot).
Solução
sudo killall -9 containerd sudo rm -f /run/containerd/containerd.sock sudo rc-service containerd start sudo rc-service docker start
Se não resolver, reiniciar a máquina é o caminho limpo, módulos do kernel podem estar inconsistentes entre versões.
# Garantir que sobem automaticamente sudo rc-update add containerd default sudo rc-update add docker default
4. Boot lento após yay -Syu
Diagnóstico
sudo rc-status --all
O elogind mostrou 00:09:31 (3) - quase 10 minutos e 3 tentativas para iniciar.
Investigação
sudo grep -i "dbus\|elogind" /var/log/rc.log | head -40
O log mostrou dbus e elogind reiniciando em loop dezenas de vezes, junto com:
WARNING: NetworkManager has started, but is inactive WARNING: netmount will start when NetworkManager has started
Causa real
Primeiro boot após um yay -Syu que atualizou NetworkManager, dbus ou elogind. Na primeira inicialização após update, serviços novos regeneram caches e configs, causando lentidão e loops temporários.
Confirmação
Reiniciar uma segunda vez normalizou completamente. O boot lento era pontual, não estrutural.
Dica: limpar o rc.log antes de reiniciar para análise limpa
sudo truncate -s 0 /var/log/rc.log
5. Core dump de 2.9GB commitado no Git
Problema
O push para o GitHub foi rejeitado:
remote: error: File core is 2754.81 MB; this exceeds GitHub's file size limit of 100.00 MB
O que é um core dump?
Quando um processo crasha no Linux, o kernel pode salvar o estado completo da memória em um arquivo chamado core no diretório atual. No caso, um processo pesado (provavelmente PHP, worker Laravel ou postgres) crashou dentro do diretório do projeto em 29 de março.
Passo 1 - Adicionar ao .gitignore e remover do tracking
echo "core" >> .gitignore echo "postgres-data/" >> .gitignore git rm --cached core git add .gitignore git commit -m "gitignore: core dumps e postgres-data"
Passo 2 - Verificar se está em commits anteriores
git log --all --full-history -- core
Se aparecer em commits mais antigos, precisa reescrever o histórico.
Passo 3 - Remover do histórico com git-filter-repo
sudo pacman -S git-filter-repo git filter-repo --path core --invert-paths --force
O --force é necessário porque o repo não é um clone fresco. O filter-repo remove o remote automaticamente após rodar.
Passo 4 - Readicionar o remote e fazer push
git remote add origin https://github.com/usuario/repo.git git push --force origin main
O --force é necessário porque o histórico foi reescrito.
6. Produção com git pull após reescrita de histórico
Problema
Após o git push --force, um git pull simples em produção gerou conflitos porque o histórico local divergia do remoto reescrito.
Solução correta em produção
git fetch --all git reset --hard origin/main
O reset --hard descarta qualquer divergência local e força o estado igual ao GitHub.
Atenção: isso descarta mudanças locais não commitadas. Faça um dump do banco antes se necessário.
Dump do banco antes de operações arriscadas
docker exec -t $(docker ps | grep postgres | awk '{print $1}') \
pg_dumpall -c -U postgres > dump_$(date +%Y%m%d_%H%M%S).sql7. Permissões do postgres-data quebradas
Causa
O git filter-repo tentou acessar postgres-data/ durante a reescrita do histórico e encontrou arquivos com permissão de root, causando erro:
error: unable to create file postgres-data/.gitkeep: Permission denied fatal: Could not reset index file to revision 'HEAD'.
Isso também quebrou o banco em produção:
SQLSTATE[08006] [7] FATAL: could not open file "global/pg_filenode.map": Permission denied
Solução
# Ver o uid do processo postgres dentro do container
docker exec $(docker ps | grep postgres | awk '{print $1}') id
# Corrigir permissões (geralmente uid 999)
sudo chown -R 999:999 postgres-data/
docker compose restart postgresImportante: o git pull em produção não mexe em permissões de arquivos existentes no servidor. O postgres-data/ deve estar no .gitignore para nunca ser commitado.
8. Evitar core dumps no diretório do projeto
Para redirecionar core dumps para fora do projeto e nunca mais ter esse problema:
echo "kernel.core_pattern=/tmp/core.%e.%p" | sudo tee -a /etc/sysctl.conf sudo sysctl -p
Assim os dumps vão para /tmp com o nome do processo e PID, facilitando diagnóstico sem risco de commitar acidentalmente.
Resumo de comandos úteis
Situação Comando
| Ver uso do zram | zramctl
| Status de todos os serviços OpenRC | sudo rc-status --all
| Limpar log do OpenRC | sudo truncate -s 0 /var/log/rc.log
| Ver o que será pushado | git log origin/main..HEAD --oneline --stat
| Ver diff completo antes do push | git diff origin/main..HEAD
| Sincronizar produção após force push | git fetch --all && git reset --hard origin/main
| Dump do postgres via docker | docker exec -t $(docker ps | grep postgres | awk '{print $1}') pg_dumpall -c -U postgres > dump.sql
| Corrigir permissões postgres-data | sudo chown -R 999:999 postgres-data/