systemd rescue.target e emergency.target: como entrar neles e voltar ao funcionamento normal

Objetivo

Inicializar em modo de resgate ou de emergência para corrigir um sistema que não consegue chegar ao target normal e, em seguida, voltar à operação normal.

Pré-requisitos

Acesso ao console para adicionar um parâmetro de kernel no menu de boot. Também é preciso a senha de root: os dois shells executam sulogin, que a solicita, e, se a conta root estiver bloqueada (o padrão no Ubuntu), o shell é recusado, a menos que sulogin seja executado com --force. Planeje isso antes de uma indisponibilidade ou use uma mídia de resgate.

Passos

1. Entenda a diferença, conforme systemd.special(7): o rescue.target "pulls in the base system (including system mounts) and spawns a rescue shell" (inclui o sistema base, com as montagens do sistema, e abre um shell de resgate). A maioria dos serviços não é iniciada, mas os sistemas de arquivos são montados e a infraestrutura básica está ativa. O emergency.target "starts an emergency shell on the main console" (abre um shell de emergência no console principal) e "does not pull in other services or mounts" (não inclui outros serviços nem montagens). É a forma mais enxuta de obter um shell, comparável a init=/bin/sh, mas com um gerenciador de serviços funcionando. O systemd também entra nesse modo por conta própria quando um sistema de arquivos necessário falha na verificação ou não pode ser montado.
2. No menu do bootloader, edite a linha de comando do kernel para uma única inicialização e acrescente systemd.unit=rescue.target ou systemd.unit=emergency.target (os aliases single/1 selecionam o modo de resgate, e emergency seleciona o modo de emergência). A alteração vale só para essa inicialização; nada é gravado em disco.
3. Observe que o estado de montagem do sistema de arquivos raiz no modo de emergência depende de como se chegou a ele: pode já estar somente leitura (por exemplo, se o boot foi feito com ro e falhou antes da etapa que o remonta) ou leitura e escrita, se a transição ocorreu depois de as montagens normais terem sido estabelecidas. Verifique com mount | grep ' / ' antes de gravar qualquer coisa e, se necessário, remonte explicitamente: mount -o remount,rw /.
4. Faça o reparo (corrigir uma linha quebrada do /etc/fstab, consertar um serviço que falha no boot, corrigir um erro em /etc/default/grub). Uma senha de root esquecida não pode ser redefinida por esse caminho, porque a entrada exige essa senha. Em sistemas baseados em dracut, rd.break, em vez disso, interrompe o boot no initramfs antes da troca de raiz, com a raiz real em /sysroot, somente leitura: mount -o remount,rw /sysroot, chroot /sysroot, passwd root e, em sistemas com SELinux, touch /.autorelabel antes de sair, ou o boot seguinte pode rejeitar logins.
5. Volte ao normal reiniciando (systemctl reboot, desta vez sem o parâmetro systemd.unit=) ou, a partir do modo de resgate e sem reiniciar, com systemctl default (também escrito systemctl isolate default.target) para iniciar o restante do sistema na sessão atual.
6. Verifique: systemctl get-default informa o target padrão configurado, e systemctl list-units --failed deve estar vazio (ou conter apenas entradas esperadas) depois do retorno a ele.

Resultado esperado

O sistema chega a um shell de usuário único ou de emergência funcional mesmo quando o boot normal não consegue terminar, e volta de forma limpa ao default.target assim que a correção está aplicada.

Limites e base de verificação

Os dois targets são acessados da mesma maneira (systemd.unit=); confundir qual deles foi solicitado é um erro comum: o resgate oferece sistemas de arquivos montados e serviços básicos, o modo de emergência não. Uma alteração de systemd.unit= no menu de boot nunca persiste além daquela inicialização; uma mudança persistente pertence à configuração do bootloader, não a este procedimento.