Resolvendo Problemas de Inicialização do Systemd: Problemas Comuns e Soluções

Os problemas de inicialização do Linux parecem urgentes porque muitas vezes você perde as ferramentas confortáveis primeiro. O SSH pode estar inativo, o login gráfico pode nunca aparecer, e o console pode te jogar no modo de emergência com uma mensagem que parece pior do que realmente é. Com problemas de inicialização do systemd, o melhor primeiro passo não é adivinhar. Encontre o ponto onde a inicialização parou, então trabalhe de volta através dos logs da unidade, falhas de montagem, erros de dependência ou mensagens iniciais do kernel.

Este guia foca em falhas que acontecem depois que o kernel iniciou o systemd como PID 1, além de alguns problemas próximos que parecem falhas do systemd pelo console: entradas ruins em /etc/fstab, problemas com initramfs e erros no carregador de inicialização.

Entendendo o Processo de Inicialização do Systemd

O Systemd gerencia o processo de inicialização do Linux através de um sistema de "unidades". Essas unidades descrevem vários recursos e serviços do sistema, como serviços (.service), pontos de montagem (.mount), dispositivos (.device) e alvos (.target). Alvos são unidades especiais que agrupam outras unidades e representam pontos de sincronização ou estados específicos durante o processo de inicialização, como multi-user.target (o tradicional runlevel 3) ou graphical.target (runlevel 5).

O processo de inicialização normalmente envolve:

1. Inicialização do Kernel: O kernel carrega e inicializa o hardware.
2. Estágio Initramfs: Um sistema de arquivos RAM inicial é carregado, que inclui drivers e ferramentas essenciais para montar o sistema de arquivos raiz.
3. Inicialização do Systemd: O Systemd assume como PID 1, iniciando o default.target (que muitas vezes é um link simbólico para multi-user.target ou graphical.target).
4. Ativação da Unidade: O Systemd lê os arquivos de unidade, resolve dependências e inicia serviços e montagens de forma altamente paralela.

Problemas de inicialização podem ocorrer em qualquer um desses estágios, mas este guia foca principalmente em problemas que se manifestam depois que o systemd foi iniciado.

Triagem Inicial: Acessando Logs de Inicialização

Quando seu sistema falha ao inicializar corretamente, o primeiro e mais crítico passo é acessar os logs de inicialização. Esses logs fornecem pistas sobre o que deu errado. Se o seu sistema não inicializar em um ambiente gráfico ou mesmo em um TTY padrão, você precisará usar métodos alternativos.

1. Usando journalctl (Do Modo de Resgate/Emergência ou Mídia ao Vivo)

journalctl é o utilitário para consultar o journal do systemd. Se o seu sistema pode inicializar no modo de resgate ou modo de emergência, ou se você está usando um USB/CD ao vivo para acessar seu disco, journalctl é sua ferramenta principal.

Para ver logs da inicialização anterior:

journalctl -b -1

Para ver todas as mensagens desde que o sistema inicializou:

journalctl -b

Para ver logs relacionados a unidades com falha:

journalctl -b -p err..emerg # Mostra erros, críticos, alertas, mensagens de emergência
journalctl -b --since "-5min" # Mostra logs dos últimos 5 minutos da inicialização atual

Se você estiver usando um ambiente ao vivo, nem sempre precisa de um chroot completo apenas para ler logs. Monte o sistema instalado e aponte o journalctl para ele:

mount /dev/mapper/vg0-root /mnt
journalctl --directory=/mnt/var/log/journal -b -1

Em sistemas sem journals persistentes, logs de inicialização mais antigos podem não existir em /var/log/journal. Nesse caso, verifique logs específicos da distribuição em /var/log, ou reproduza a inicialização após ativar o journal persistente quando o sistema estiver saudável o suficiente para fazê-lo.

2. Usando dmesg

dmesg exibe o buffer de anel do kernel, que contém mensagens do kernel durante a inicialização. Isso é especialmente útil para problemas que ocorrem muito cedo no processo de inicialização, antes que o systemd tenha assumido completamente.

dmesg

3. Examinando o Status da Unidade

Uma vez em um shell utilizável (modo de resgate, modo de emergência ou ambiente ao vivo com chroot), você pode verificar o status de todas as unidades do systemd.

systemctl --failed

Este comando lista todas as unidades que falharam ao iniciar. Para informações detalhadas sobre uma unidade com falha específica, use:

systemctl status <nome_da_unidade>.service

E para ver suas entradas de journal específicas:

journalctl -u <nome_da_unidade>.service -b

Problemas Comuns de Inicialização do Systemd e Soluções

1. Serviços com Falha e Falhas de Unidade

Problema: Um serviço crítico falha ao iniciar, impedindo o sistema de atingir o alvo desejado (ex.: multi-user.target). Isso geralmente se manifesta com o sistema caindo no modo de emergência.

Sintomas: systemctl --failed mostra uma ou mais unidades com estado "failed". journalctl -u <nome_da_unidade>.service revela mensagens de erro indicando por que o serviço não pôde iniciar.

Causas Comuns:

• Configuração Incorreta: Erro de digitação em um arquivo de configuração, caminhos incorretos, dependências ausentes.
• Arquivos/Dependências Ausentes: Um serviço tenta acessar um arquivo ou diretório que não existe ou está inacessível.
• Exaustão de Recursos: O serviço tenta alocar muita memória ou outros recursos.
• Problemas de Permissão: O serviço não tem as permissões necessárias para ler/escrever arquivos ou executar comandos.

Soluções:

1. Identifique a Unidade com Falha: Use systemctl --failed.
2. Inspecione os Logs: Execute journalctl -u <nome_da_unidade>.service -b para mensagens de erro detalhadas.
3. Corrija a Configuração: Edite o arquivo de configuração do serviço (ex.: /etc/systemd/system/<nome_da_unidade>.service ou arquivos em /etc/). Preste atenção às diretivas ExecStart, WorkingDirectory, User, Group, Environment.
4. Verifique as Dependências: Certifique-se de que todas as diretivas Wants=, Requires=, After=, Before= estão especificadas corretamente e que os serviços necessários estão habilitados.
5. Reinicie e Reabilite: Após fazer alterações, execute systemctl daemon-reload, então tente systemctl start <nome_da_unidade>.service e systemctl enable <nome_da_unidade>.service.

Exemplo: Um serviço web personalizado mywebapp.service falha porque seu banco de dados não está disponível.

# Verifique o status
systemctl status mywebapp.service

# Verifique os logs para pistas
journalctl -u mywebapp.service -b

# Edite o arquivo de unidade (ex.: em /etc/systemd/system/mywebapp.service)
# Adicione/modifique a diretiva After= para garantir que o banco de dados inicie primeiro
# ex.: After=postgresql.service mysql.service

# Recarregue o systemd e tente novamente
systemctl daemon-reload
systemctl start mywebapp.service
systemctl enable mywebapp.service # Garanta que ele inicie na próxima inicialização

2. Problemas de Sistema de Arquivos

Problema: Sistemas de arquivos corrompidos ou entradas incorretas em /etc/fstab podem impedir o sistema de montar partições críticas, levando ao modo de emergência.

Sintomas: Mensagens de erro sobre falhas de fsck, erros de mount, ou o sistema caindo no modo de emergência com uma mensagem como "Forneça a senha de root para manutenção (ou digite Control-D para continuar)".

Causas Comuns:

• Sistema de Arquivos Sujo: Desligamento inadequado, falta de energia.
• /etc/fstab Incorreto: Erro de digitação no UUID/caminho do dispositivo, tipo de sistema de arquivos errado, noauto ausente para montagens não críticas.
• Falha de Hardware: Corrupção de disco.

Soluções:

1. Acesse o Modo de Emergência: Se solicitado, digite a senha de root.
2. Verifique /etc/fstab: Revise cuidadosamente /etc/fstab em busca de erros. Comente linhas suspeitas temporariamente com #.
3. Execute fsck com cuidado: Verifique e repare manualmente os sistemas de arquivos apenas quando eles estiverem desmontados, ou montados como somente leitura em um contexto de manutenção onde sua distribuição documente como seguro. Para uma partição que não seja a raiz:

   umount /dev/sdb1
   fsck -f /dev/sdb1
   

   Se o sistema de arquivos raiz precisar de reparo, inicialize a partir de mídia ao vivo ou um ambiente de resgate e execute fsck a partir daí. Evite fsck -y como primeiro movimento em discos importantes; revise os prompts a menos que você já tenha um backup ou entenda o dano.
4. Reinicialize: Após fazer alterações ou executar fsck, tente reinicializar.

3. Conflitos de Dependência e Ordenação de Unidades

Problema: Serviços iniciam na ordem errada, ou unidades têm dependências conflitantes, levando a deadlocks ou falhas.

Sintomas: Serviços expirando, serviços falhando porque suas dependências não estão prontas, systemd-analyze plot mostrando cadeias longas ou ciclos.

Causas Comuns:

• Diretivas Wants=, Requires=, After=, Before= mal configuradas em arquivos de unidade.
• Unidades esperando recursos que ainda não estão disponíveis.

Soluções:

1. Analise a Sequência de Inicialização: Use systemd-analyze para visualizar o processo de inicialização.

   • systemd-analyze blame: Mostra serviços ordenados pelo seu tempo de inicialização, destacando unidades lentas.
   • systemd-analyze critical-chain: Mostra o caminho crítico de unidades que impactam diretamente o tempo total de inicialização.
   • systemd-analyze plot > boot.svg: Gera uma imagem SVG de todo o gráfico de dependência de inicialização, inestimável para problemas complexos.

2. Inspecione as Dependências da Unidade: Use systemctl list-dependencies <nome_da_unidade> para ver o que uma unidade requer e o que depende dela.

3. Ajuste as Diretivas do Arquivo de Unidade:

   • After=, Before=: Controlam a ordenação das unidades. Se A.service tem After=B.service, A iniciará após B (se B for iniciado). Use After= para a maioria das necessidades de ordenação.
   • Wants=: Expressa uma dependência fraca. Se A.service Wants=B.service, B será iniciado quando A iniciar, mas A continuará mesmo se B falhar.
   • Requires=: Expressa uma dependência forte. Se A.service Requires=B.service, B é puxado quando A inicia, e A falha se B não puder ser iniciado. Se B for explicitamente parado, A também é parado.
   • Conflicts=: Garante que uma unidade específica seja parada se a unidade atual for iniciada, e vice-versa.
   • PartOf=: Liga o ciclo de vida de uma unidade a outra (ex.: se uma slice é parada, todas as unidades PartOf dela também são paradas).

   Dica: Sempre prefira After= e Wants= para a maioria das dependências para evitar criar um acoplamento forte que possa levar a deadlocks ou cascatas de falhas.

4. Pânicos do Kernel / Problemas de Initramfs

Problema: O sistema falha ao inicializar muito cedo, muitas vezes antes do systemd assumir completamente, exibindo mensagens como "Kernel panic - not syncing" ou relacionadas a dracut ou initramfs.

Sintomas: Falha de inicialização precoce, muitas vezes com uma parede de texto mostrando rastreamentos de pilha ou mensagens sobre dispositivo raiz ausente, /dev/root não encontrado, etc.

Causas Comuns:

• Módulos do Kernel Ausentes: O Initramfs não contém drivers necessários para o sistema de arquivos raiz (ex.: LVM, RAID, controladores de disco específicos).
• Kernel/Initramfs Corrompido: Arquivos estão danificados.
• Parâmetros do Kernel Incorretos: O parâmetro root= no GRUB aponta para o dispositivo errado.

Soluções:

1. Reconstrua o Initramfs: Esta é uma correção comum. Inicialize em um ambiente ao vivo ou outro kernel, faça chroot no seu sistema e reconstrua o initramfs.

   # Exemplo para Dracut (Fedora/RHEL/CentOS)
   dracut -f -v /boot/initramfs-$(uname -r).img $(uname -r)
   
   # Exemplo para mkinitcpio (Arch Linux)
   mkinitcpio -P
   
   # Exemplo para update-initramfs (Debian/Ubuntu)
   update-initramfs -u -k all
   

2. Verifique a Configuração do GRUB: Verifique /boot/grub/grub.cfg (ou /etc/default/grub se você o regenerar) para o parâmetro root= correto e o caminho initrd.
3. Parâmetros do Kernel: Se você suspeitar que um módulo específico está ausente ou causando problemas, você pode tentar adicionar parâmetros do kernel no GRUB (ex.: rd.break para entrar no shell do initramfs para depuração).

5. Problemas com GRUB/Carregador de Inicialização

Problema: O sistema não chega nem ao ponto onde o kernel carrega, ou fica preso no menu do GRUB.

Sintomas: "Nenhum dispositivo de inicialização encontrado", prompt de resgate do GRUB, ou GRUB falha ao carregar o kernel.

Causas Comuns:

• Carregador de inicialização corrompido.
• Configuração incorreta do GRUB apontando para kernel/initramfs inexistente.
• Configurações de BIOS/UEFI impedindo a ordem de inicialização correta.

Soluções:

1. Reinstale o GRUB: Inicialize a partir de um USB ao vivo, faça chroot no seu sistema e reinstale o GRUB no MBR/partição EFI.

   # Exemplo
   mount /dev/sdaX /mnt # Monte a partição raiz
   
   mount /dev/sdaY /mnt/boot/efi # Se partição EFI separada
   
   for i in /dev /dev/pts /proc /sys /run; do mount --bind $i /mnt$i; done
   chroot /mnt
   
   grub-install /dev/sda # Instale no disco principal
   
   grub-mkconfig -o /boot/grub/grub.cfg # Regere a configuração do GRUB
   
   exit
   umount -R /mnt
   reboot
   

2. Verifique as Configurações de BIOS/UEFI: Certifique-se de que a unidade de inicialização correta está priorizada.

Técnicas Avançadas de Solução de Problemas

Inicializando no Modo de Resgate/Emergência

Esses modos fornecem um ambiente mínimo para solucionar problemas. Para entrar neles:

1. Durante o GRUB: Pressione e para editar a linha de comando do kernel.
2. Localize a linha linux: Encontre a linha começando com linux (ou linuxefi).
3. Adicione systemd.unit=rescue.target para o modo de resgate (a maioria dos serviços está desligada, shell de usuário único).
4. Adicione systemd.unit=emergency.target para o modo de emergência (serviços mínimos, raiz geralmente somente leitura).
5. Pressione Ctrl+X ou F10 para inicializar.

Usando rd.break para Depuração de Initramfs

Adicionar rd.break à linha de comando do kernel no GRUB irá te jogar em um shell dentro do initramfs antes que o sistema de arquivos raiz real seja montado. Isso é extremamente útil para depurar problemas de initramfs, como drivers ausentes ou problemas com configuração de LVM/RAID.

Uma vez no shell do initramfs, você pode:

• Inspecionar lsblk, mount.
• Verificar arquivos ausentes em /sysroot.
• Tentar montar manualmente o sistema de arquivos raiz.

Analisando o Desempenho da Inicialização

Embora não seja estritamente uma "falha", tempos de inicialização lentos podem indicar problemas subjacentes ou configurações de serviço ineficientes.

• systemd-analyze blame: Identifique serviços que demoram mais para iniciar.
• systemd-analyze critical-chain: Entenda o caminho crítico de dependências que impactam o tempo total de inicialização.

Uma Sequência de Recuperação Segura

Quando você está no console e a máquina está meio inicializada, mantenha a sequência de recuperação simples:

1. Capture o erro exato na tela se puder.
2. Execute systemctl --failed.
3. Leia journalctl -b -p err..alert --no-pager.
4. Se uma unidade falhou, leia journalctl -u nome-da-unidade -b.
5. Se uma montagem falhou, inspecione /etc/fstab, verifique os UUIDs com blkid e comente apenas a montagem não crítica suspeita.
6. Se o sistema de arquivos raiz ou initramfs estiver envolvido, mude para mídia ao vivo ou modo de resgate antes de fazer reparos invasivos.
7. Após edições no arquivo de unidade, execute systemctl daemon-reload e reinicie apenas a unidade afetada quando possível.

A maioria dos problemas de inicialização do systemd não é corrigida mudando muitas coisas de uma vez. Uma linha de montagem ruim, um disco ausente, um serviço com um ExecStart= quebrado ou um erro de ordenação deixa um rastro bastante direto. Siga esse rastro, faça um pequeno reparo e reinicie apenas quando o shell atual não puder testar a correção.

Use essas ferramentas para identificar gargalos e otimizar a inicialização da unidade ajustando as diretivas After=, Requires=, TimeoutStartSec= ou Type=.

Prevenção e Melhores Práticas

• Teste as Alterações: Antes de implantar modificações em arquivos de unidade em produção, teste-as em um ambiente de homologação.
• Faça Backup da Configuração: Faça backup regularmente de /etc/ ou pelo menos dos arquivos críticos de /etc/systemd/system/.
• Entenda as Diretivas de Unidade: Uma compreensão sólida das páginas de manual systemd.service(5) e systemd.unit(5) é inestimável.
• Use Arquivos Drop-in: Em vez de modificar diretamente os arquivos de unidade de /lib/systemd/system/ (que podem ser sobrescritos por atualizações), use arquivos drop-in (/etc/systemd/system/<nome_da_unidade>.service.d/*.conf) para configurações personalizadas.
• Mantenha Kernels: Sempre mantenha pelo menos um kernel antigo conhecido como bom em seu sistema para inicializar se um novo kernel causar problemas.

Conclusão

Resolver problemas de inicialização do systemd requer uma abordagem sistemática, começando com uma análise eficaz de logs. Ao entender a arquitetura baseada em unidades do systemd e aproveitar ferramentas como journalctl, systemctl e systemd-analyze, você pode identificar eficientemente a causa raiz das falhas de inicialização, seja um serviço mal configurado, um problema de sistema de arquivos ou um conflito de dependência complexo. A capacidade de inicializar em modos de resgate ou emergência, juntamente com técnicas avançadas de depuração, permite que você recupere o controle do seu sistema mesmo quando ele parece completamente sem resposta. Com essas estratégias e melhores práticas, você estará bem equipado para enfrentar a maioria dos desafios de inicialização do systemd e manter operações Linux estáveis e confiáveis.