Comando reboot no Linux: reboot, shutdown -r now, systemctl

O comando de reinicialização do Linux: reboot, shutdown -r now e systemctl reboot

Em qualquer distribuição atual, os três comandos abaixo reiniciam a máquina exatamente da mesma forma. Execute um deles como root ou via sudo; por SSH, uma conta sem privilégios recebe Failed to reboot system via logind: Interactive authentication required.

sudo reboot
sudo shutdown -r now
sudo systemctl reboot

Não são três implementações diferentes. Nas distribuições com systemd, /sbin/reboot, /sbin/shutdown, /sbin/halt e /sbin/poweroff são links simbólicos para systemctl, que verifica sob qual nome foi invocado e passa para o modo de compatibilidade correspondente; ls -l $(which reboot) mostra o link. Qualquer que seja a forma digitada, o systemd inicia reboot.target, para todas as units na ordem inversa das dependências, desmonta os sistemas de arquivos e pede ao kernel para reiniciar. Por SSH, a conexão cai em um ou dois segundos; quanto tempo a máquina fica fora depende do kernel, de eventuais verificações de sistema de arquivos e do caminho de boot do provedor, então espere um minuto antes de supor que algo deu errado.

Desligar: shutdown -h now, poweroff, halt e o antigo init 6

Para desligar a máquina, qualquer um destes serve:

sudo shutdown -h now
sudo poweroff          # identical to: sudo systemctl poweroff

No systemd, -h significa "halt ou desligar, o que for o padrão", e o padrão é desligar, portanto shutdown -h now e shutdown -P now são idênticos. O comando que engana muita gente é o halt puro: ele para o sistema operacional, mas nunca envia o pedido de desligamento, então a máquina virtual fica parada em System halted, ainda alocada e ainda cobrada, até você pará-la pelo painel. Use halt -p, poweroff ou shutdown -h now no lugar.

As formas SysV ainda funcionam porque o systemd mapeia os runlevels em targets: init 6 e telinit 6 resolvem para reboot.target, e init 0 para poweroff.target. São inofensivas dentro de um script antigo, mas não oferecem mensagem wall, nem agendamento, nem registro no journal, então não há motivo para digitá-las à mão.

Agendar um reinício, cancelá-lo e avisar os usuários conectados

sudo shutdown -r +10 "Kernel update, back in about two minutes"
sudo shutdown -r 02:30
sudo shutdown -c

O horário pode ser now, +m para m minutos a partir de agora, ou hh:mm no formato de 24 horas (um horário já passado hoje significa amanhã). Sem nenhum horário, o shutdown assume +1: um sudo shutdown sozinho desliga a máquina em sessenta segundos. Tudo o que vem depois do horário é transmitido como mensagem wall a todos os terminais conectados, e o logind repete o aviso conforme o prazo se aproxima; --no-wall silencia isso, e shutdown -k envia o aviso sem agendar nada. Cinco minutos antes do prazo, o logind cria /run/nologin e novos logins passam a ser recusados.

shutdown -c cancela a operação pendente, remove /run/nologin e informa aos usuários conectados que o desligamento foi cancelado. Para verificar se há um agendado, procure /run/systemd/shutdown/scheduled: ele só existe enquanto houver um desligamento na fila e registra o modo e o horário alvo. Versões recentes do systemd também aceitam systemctl reboot --when=+10m, com --when=show e --when=cancel (confira systemctl --help; versões antigas não têm).

O que acontece com os serviços e as sessões SSH durante um reinício

Quando reboot.target é solicitado, o systemd para tudo que conflita com ele, ou seja, quase todas as units. Os serviços param na ordem inversa das dependências: cada um executa seu ExecStop ou recebe SIGTERM e, se não tiver encerrado após TimeoutStopSec (90 segundos por padrão, vindo de DefaultTimeoutStopSec= em /etc/systemd/system.conf), recebe SIGKILL. Esse tempo limite é a contagem regressiva A stop job is running for ... vista no console; normalmente um daemon que ignora o SIGTERM ou um banco de dados ainda gravando. Em seguida, os sistemas de arquivos são desmontados ou remontados somente leitura e o kernel reinicia. Não é preciso executar sync antes.

Sua sessão SSH não recebe tratamento especial. O ssh.service para, o scope que contém seu login recebe SIGTERM, seu shell morre e o cliente exibe Connection to 203.0.113.10 closed by remote host. Um servidor tmux ou screen protege você de uma queda de conexão, não de um reinício: tudo o que roda dentro dele também desaparece.

O que volta é definido pela habilitação, não pelo que estava rodando. As units marcadas como enabled iniciam de novo; o que foi lançado à mão com systemctl start, um processo nohup ou um contêiner Docker sem política de reinício, não. Execute systemctl list-unit-files --state=enabled antes e systemctl --failed depois; o guia sobre listar e filtrar serviços com o systemctl explica como ler os dois.

Reiniciar um VPS com segurança: a checklist antes do reinício

Em um VPS não há acesso físico, então um reinício que não volta significa um desvio pelo console do provedor. Cinco verificações, menos de um minuto no total, evitam quase todos esses desvios.

1. Confirme que o reinício é mesmo necessário

Nem toda atualização exige um. No Ubuntu, /var/run/reboot-required existe quando um pacote pediu reinício e /var/run/reboot-required.pkgs diz qual foi; needrestart no Debian e no Ubuntu, e needs-restarting -r do dnf-utils na família RHEL, fazem a mesma verificação em outros sistemas. Um kernel novo, glibc ou systemd justificam um reinício; um nginx corrigido só precisa de systemctl restart nginx. Instale primeiro as atualizações pendentes para reiniciar uma vez, não duas; o passo a passo sobre atualizar o Ubuntu pela linha de comando cobre a sequência do apt e o sinalizador reboot-required.

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs
uname -r; ls /boot/vmlinuz-*     # running kernel vs. newest installed

2. Garanta que nada esteja no meio de uma gravação

Interromper um gerenciador de pacotes é o caminho mais rápido para um sistema meio configurado, e um backup morto pela metade é um arquivo que você mais tarde vai confundir com uma cópia boa. Procure esses processos e veja quem mais está conectado:

pgrep -a 'apt|dpkg|dnf|yum|unattended'
pgrep -a 'rsync|mysqldump|pg_dump|restic|borg'
w

3. Valide a configuração que precisa sobreviver ao boot

Três arquivos transformam um reinício de rotina em um bloqueio de acesso. Um erro de sintaxe em sshd_config faz o sshd não iniciar e você não consegue mais entrar: sudo sshd -t não imprime nada quando o arquivo é válido e, se você recentemente reforçou a segurança do daemon SSH, execute-o agora. Uma entrada em /etc/fstab para um dispositivo que não existe mais leva o boot ao modo de emergência, a menos que tenha nofail; sudo findmnt --verify detecta a maior parte disso. Um /boot cheio pode deixar um kernel instalado pela metade, então verifique o espaço livre. Regras de firewall escritas diretamente com iptables ou nft e nunca salvas somem no reinício; as regras do UFW e do firewalld persistem.

sudo sshd -t
sudo findmnt --verify
df -h / /boot

4. Registre um estado de referência

systemctl --failed
systemctl list-units --type=service --state=running > ~/services-before.txt

5. Reinicie e depois verifique

sudo systemctl reboot --message="post-update reboot"
# after reconnecting:
uptime -s; systemctl --failed
systemctl list-units --type=service --state=running | diff ~/services-before.txt -

Um uname -r correspondente, um systemctl --failed limpo e um diff vazio significam que o reinício cumpriu seu papel.

Quando o reinício trava: como forçá-lo e quando recorrer ao console do provedor

Se o reboot retorna mas a máquina nunca desce, há um stop job travado; systemctl list-jobs mostra qual. systemctl reboot --force pula o desligamento ordenado das units: os processos são mortos de imediato, mas os sistemas de arquivos ainda são desmontados, então é abrupto porém razoavelmente seguro. --force --force reinicia na hora sem desmontar nada e pode causar perda de dados; encare como tirar o cabo da tomada. A interface SysRq do kernel é o último recurso quando o próprio systemd não responde mais. Escrever em /proc/sysrq-trigger é sempre permitido ao root, independentemente do sysctl kernel.sysrq, mas o redirecionamento precisa rodar como root, então use um shell de root ou sudo sh -c:

echo s > /proc/sysrq-trigger   # sync dirty buffers
echo u > /proc/sysrq-trigger   # remount filesystems read-only
echo b > /proc/sysrq-trigger   # reboot right now

Recorra ao painel ou ao console do provedor quando o sistema convidado não puder mais se ajudar: SSH inacessível após uma mudança de rede ou de firewall, um kernel que entra em panic no boot, um prompt de modo de emergência por causa de uma linha errada no fstab, uma senha de root esquecida. Reboot ou Shutdown em um painel normalmente envia um evento ACPI de energia que o convidado trata pelo logind (HandlePowerKey= em logind.conf), então os serviços ainda param de forma limpa. Reset, Force stop ou Power cycle corta a energia virtual sem aviso: o journal do sistema de arquivos é reaplicado no próximo boot, mas tudo o que não foi gravado se perde. O console VNC ou serial é o que permite acompanhar o GRUB, as mensagens do kernel e o shell de emergência que o SSH nunca mostra.

Verificar o uptime e quando a máquina reiniciou pela última vez

uptime -p                      # up 3 days, 4 hours, 12 minutes
uptime -s                      # 2026-08-31 02:31:07
who -b                         # system boot  2026-08-31 02:31
last -x reboot shutdown | head
journalctl --list-boots

uptime -s e who -b imprimem o horário do boot diretamente. last -x lê /var/log/wtmp e lista os registros de reboot e de shutdown: uma linha reboot sem uma linha shutdown antes dela significa que a máquina caiu de forma suja (um panic ou um reset forçado). journalctl --list-boots numera todos os boots que o journal conhece, sendo 0 o atual e -1 o anterior; journalctl -b -1 -e mostra então as últimas linhas antes do desligamento anterior, onde um tempo limite de stop job ou uma morte por falta de memória deixa seu rastro. Se apenas o boot atual aparecer, o journal é volátil: crie /var/log/journal e reinicie o systemd-journald.

Todo comando acima parte de um pressuposto: quando o sistema convidado se recusa a voltar, você ainda consegue alcançá-lo. Um VPS Linux KVM com acesso ao console dá exatamente isso: uma máquina virtual real com kernel próprio, CPU e RAM dedicadas, root completo e um console para os dias em que o SSH não é opção. A rdp.monster entrega um cerca de 10 segundos após a confirmação do pagamento, com largura de banda ilimitada (fair-use), sem KYC, aceitando cartões e cripto, a partir de $8.99/mês.