Linux Reboot Command: reboot, shutdown -r now, systemctl reboot

The Linux reboot command: reboot, shutdown -r now and systemctl reboot

On any current distribution the three commands below restart the machine in exactly the same way. Run one of them as root or through sudo; over SSH an unprivileged account gets Failed to reboot system via logind: Interactive authentication required.

sudo reboot
sudo shutdown -r now
sudo systemctl reboot

These are not three implementations. On systemd distributions /sbin/reboot, /sbin/shutdown, /sbin/halt and /sbin/poweroff are symlinks to systemctl, which checks the name it was invoked under and switches to the matching compatibility mode; ls -l $(which reboot) shows the link. Whichever spelling you type, systemd starts reboot.target, stops every unit in reverse dependency order, unmounts the filesystems and asks the kernel to restart. Over SSH the connection drops within a second or two; how long the machine stays away depends on the kernel, on any filesystem check and on the provider's boot path, so allow a minute before assuming trouble.

Shutting down: shutdown -h now, poweroff, halt and the legacy init 6

To power the machine off, either of these will do:

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

Under systemd, -h means "halt or power off, whichever is the default", and the default is power off, so shutdown -h now and shutdown -P now are identical. The command that catches people out is plain halt: it stops the operating system but never sends the power-off request, so a virtual machine sits at System halted, still allocated and still billed, until you stop it from the panel. Use halt -p, poweroff or shutdown -h now instead.

The SysV forms still work because systemd maps runlevels onto targets: init 6 and telinit 6 resolve to reboot.target, init 0 to poweroff.target. They are harmless in an old script but offer no wall message, no scheduling and no journal note, so there is no reason to type them by hand.

Scheduling a reboot, cancelling it and warning logged-in users

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

The time can be now, +m for m minutes from now, or hh:mm in 24-hour format (a time already past today means tomorrow). With no time at all, shutdown assumes +1: a bare sudo shutdown powers the machine off in sixty seconds. Everything after the time is broadcast as a wall message to every logged-in terminal, and logind repeats the warning as the deadline nears; --no-wall keeps it quiet, and shutdown -k sends the warning without scheduling anything. Five minutes before the deadline logind creates /run/nologin, and new logins are refused from then on.

shutdown -c cancels the pending operation, removes /run/nologin and tells logged-in users the shutdown was cancelled. To check whether one is pending, look for /run/systemd/shutdown/scheduled: it exists only while a shutdown is queued and records the mode and target time. Recent systemd releases also accept systemctl reboot --when=+10m, with --when=show and --when=cancel (check systemctl --help; older releases lack it).

What happens to services and SSH sessions during a reboot

When reboot.target is requested, systemd stops everything that conflicts with it, which is nearly every unit. Services stop in reverse dependency order: each runs its ExecStop or receives SIGTERM, and if it has not exited after TimeoutStopSec (90 seconds by default, from DefaultTimeoutStopSec= in /etc/systemd/system.conf) it gets SIGKILL. That timeout is the A stop job is running for ... countdown seen on a console; usually a daemon that ignores SIGTERM or a database still flushing. Filesystems are then unmounted or remounted read-only and the kernel restarts. You do not need to run sync first.

Your SSH session gets no special treatment. ssh.service stops, the scope holding your login receives SIGTERM, your shell dies and the client prints Connection to 203.0.113.10 closed by remote host. A tmux or screen server protects you from a dropped connection, not from a reboot: whatever runs inside it is gone too.

What comes back is decided by enablement, not by what was running. Units marked enabled start again; anything launched by hand with systemctl start, a nohup process or a Docker container without a restart policy does not. Run systemctl list-unit-files --state=enabled before and systemctl --failed after; the guide to listing and filtering services with systemctl explains how to read both.

Rebooting a VPS safely: the pre-flight checklist

On a VPS there is no physical access, so a reboot that does not come back means a detour through the provider's console. Five checks, under a minute in total, prevent almost every such detour.

1. Confirm the reboot is actually needed

Not every update requires one. On Ubuntu, /var/run/reboot-required exists when a package asked for a restart and /var/run/reboot-required.pkgs names it; needrestart on Debian and Ubuntu, and needs-restarting -r from dnf-utils on the RHEL family, do the same check elsewhere. A new kernel, glibc or systemd justifies a reboot; a patched nginx only needs systemctl restart nginx. Install pending updates first so you reboot once, not twice; the walkthrough on updating Ubuntu from the command line covers the apt sequence and the reboot-required flag.

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

2. Make sure nothing is mid-write

Interrupting a package manager is the quickest route to a half-configured system, and a backup killed halfway through is a file you will later mistake for a good copy. Look for those processes and see who else is logged in:

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

3. Validate the configuration that must survive the boot

Three files turn a routine reboot into a lockout. A syntax error in sshd_config means sshd will not start and you cannot get back in: sudo sshd -t prints nothing when the file is valid, and if you recently hardened the SSH daemon, run it now. An /etc/fstab entry for a device that no longer exists drops the boot into emergency mode unless it carries nofail; sudo findmnt --verify catches most of that. A full /boot can leave a half-installed kernel behind, so check its free space. Firewall rules written directly with iptables or nft and never saved vanish on reboot; UFW and firewalld rules persist.

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

4. Take a baseline

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

5. Reboot, then verify

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

A matching uname -r, a clean systemctl --failed and an empty diff mean the reboot did its job.

When reboot hangs: forcing it, and when to use the provider console instead

If reboot returns but the machine never goes down, a stop job is stuck; systemctl list-jobs shows which one. systemctl reboot --force skips the orderly unit shutdown: processes are killed outright but filesystems are still unmounted, so it is abrupt yet reasonably safe. --force --force reboots immediately without unmounting anything and can lose data; treat it as pulling the plug. The kernel's SysRq interface is the final resort when systemd itself no longer answers. Writing to /proc/sysrq-trigger is always allowed for root whatever the kernel.sysrq sysctl says, but the redirection must run as root, so use a root shell or 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

Reach for the provider's panel or console when the guest can no longer help itself: SSH unreachable after a network or firewall change, a kernel that panics on boot, an emergency-mode prompt from a bad fstab line, a forgotten root password. Reboot or Shutdown in a panel normally sends an ACPI power event that the guest handles through logind (HandlePowerKey= in logind.conf), so services still stop cleanly. Reset, Force stop or Power cycle cuts the virtual power with no warning: the filesystem journal replays on the next boot, but anything unwritten is lost. The VNC or serial console is what lets you watch GRUB, the kernel messages and the emergency shell that SSH never shows you.

Checking uptime and when the machine last rebooted

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 and who -b print the boot time directly. last -x reads /var/log/wtmp and lists both reboot and shutdown records: a reboot line with no shutdown line before it means the machine went down uncleanly (a panic or a hard reset). journalctl --list-boots numbers every boot the journal knows about, 0 being the current one and -1 the previous; journalctl -b -1 -e then shows the last lines before the previous shutdown, where a stop-job timeout or an out-of-memory kill leaves its trace. If only the current boot is listed, the journal is volatile: create /var/log/journal and restart systemd-journald.

Every command above rests on one assumption: that when the guest refuses to come back, you can still reach it. A KVM Linux VPS with console access gives you exactly that, a real virtual machine with its own kernel, dedicated CPU and RAM, full root, and a console for the days when SSH is not an option. rdp.monster delivers one about 10 seconds after payment confirms, with unlimited (fair-use) bandwidth, no KYC, cards and crypto accepted, from $8.99/month.