Boot, Reboot and Shut Down Linux with systemd

When a kernel update lands or a maintenance window opens, you need the host to leave runlevel cleanly, come back with a fresh boot ID, and give logged-in users time to save work. systemd exposes that through systemctl verbs and the legacy shutdown front end, which still schedules timed jobs on current RHEL and Fedora releases.

Linux Shutdown and Reboot Commands Explained

Four words show up in every power-management cheat sheet. They overlap in documentation but point at different end states.

On systemd hosts, immediate actions map to systemctl verbs. shutdown remains convenient for traditional +MINUTES / HH:MM scheduling and wall messages, while current systemctl also supports scheduled halt, poweroff, and reboot through --when=.

Shutdown and Reboot Quick Reference

Keep this table nearby. Commands assume root or sudo.

shutdown --help on RHEL 10 documents -h as halt or poweroff unless you pass -H for halt-only semantics, and recommends systemctl for immediate transitions.

Reboot Linux Safely

A safe reboot gives services a clean stop, flushes what they can, and returns the host with a new boot ID you can verify from another session.

Use systemctl reboot

systemctl reboot asks systemd to start the reboot.target transaction. It is the explicit spelling administrators use when they already manage other units through systemctl.

sudo systemctl reboot

The command returns immediately while shutdown proceeds in the background. Your SSH session closes when networking and sshd stop, so do not wait for a shell prompt on the same connection.

Legacy reboot command

sudo reboot

On RHEL 10, /usr/sbin/reboot is a systemd compatibility entry point. Behavior matches systemctl reboot for most administrators.

What happens to services and sessions

systemd stops units in dependency order. User logins receive warnings if a scheduled shutdown is active. Processes that ignore SIGTERM get SIGKILL after timeout. Remote SSH sessions end when sshd exits; unsaved editor buffers in those sessions are lost unless the editor traps hangup.

After the machine returns, confirm uptime moved forward and critical units are active before you declare the window complete.

uptime

Sample output:

14:46:54 up 16:04,  1 user,  load average: 2.42, 2.50, 1.58

The up duration resets after a successful reboot. Compare it with the maintenance window you planned.

Shut Down and Power Off Linux

Power off is appropriate when the host should stay offline—decommissioning a VM, moving hardware, or closing a lab for the night.

sudo systemctl poweroff

The companion compatibility command is:

sudo poweroff

Both request poweroff.target, which stops user services and asks the platform to remove power when ACPI or the hypervisor supports it.

Reboot and poweroff differ only in the final target: reboot runs reboot.target and starts firmware again; poweroff runs poweroff.target and does not bring the OS back until someone powers the machine on or starts a VM.

Do not run poweroff on the machine you are SSH'd into unless you intend to lose that connection immediately.

Halt vs Poweroff

For systemd, halt and poweroff are separate transactions—not a single path where poweroff continues through halt.target.

systemctl halt enqueues halt.target and halts the OS while leaving hardware powered on. systemctl poweroff enqueues poweroff.target and additionally requests platform power-off through ACPI or firmware when the platform supports it.

sudo systemctl halt

sudo systemctl poweroff

A hypervisor or cloud console may show a halted guest as stopped even though power was not removed at the chassis. That display behavior does not make halt and poweroff equivalent: only poweroff asks the platform to drop power.

Default to poweroff when the machine should stay off. Use halt when you need the OS stopped but hardware still powered—for example, some bare-metal maintenance flows.

shutdown -H requests halt semantics through the shutdown front end; shutdown -h without -H maps to poweroff on current systemd releases.

Schedule with systemctl --when=

On systemd 257, systemctl halt, poweroff, and reboot accept --when= for delayed power events. RHEL 10 documents the same pattern for scheduled poweroff and halt with strings such as +15min.

Schedule a reboot fifteen minutes ahead:

sudo systemctl reboot --when="+15min"

Sample output:

Reboot scheduled for Sat 2026-08-08 14:47:46 IST, use 'systemctl reboot --when=cancel' to cancel.

Read the pending job with --when=show on any of the power verbs—they share one shutdown queue:

sudo systemctl reboot --when=show

Sample output:

Reboot scheduled for Sat 2026-08-08 14:47:46 IST, use 'systemctl reboot --when=cancel' to cancel.

Schedule poweroff with the same time syntax:

sudo systemctl poweroff --when="+20min"

Sample output:

Shutdown scheduled for Sat 2026-08-08 14:52:46 IST, use 'systemctl poweroff --when=cancel' to cancel.

Cancel before the timer fires:

sudo systemctl reboot --when=cancel

The command exits silently on success. Confirm the queue is empty:

sudo systemctl poweroff --when=show

Sample output:

No scheduled shutdown.

Use --when= when you already manage the host through systemctl and want ISO-style durations such as +15min without the shutdown front end. Use shutdown when you need HH:MM wall-clock scheduling or the traditional +MINUTES spelling.

Schedule a Shutdown

Timed shutdowns give users a countdown and let you cancel if a dependency slips.

Relative delay

+MINUTES schedules from the current clock. The message string is optional but recommended.

sudo shutdown -h +20 "maintenance test"

Sample output:

Shutdown scheduled for Sat 2026-08-08 10:44:04 IST, use 'shutdown -c' to cancel.

systemd records the job under /run/systemd/shutdown/scheduled.

cat /run/systemd/shutdown/scheduled

Sample output:

USEC=1786166044599291
WARN_WALL=1
MODE=poweroff
UID=0
WALL_MESSAGE=maintenance\x20test

MODE=poweroff confirms this job powers off rather than reboots. WARN_WALL=1 means users should see wall traffic as the deadline approaches.

Absolute time

Pass HH:MM in 24-hour local time. If that time already passed today, the schedule rolls to the next day.

sudo shutdown 14:30 "At time test"

Sample output:

Shutdown scheduled for Sat 2026-08-08 14:30:00 IST, use 'shutdown -c' to cancel.

nologin and new logins

When a timed shutdown reaches five minutes remaining, systemd creates /run/nologin to block new interactive logins. It is therefore normal not to see the file immediately after scheduling a +10 or +20 shutdown—the five-minute gate has not opened yet.

Do not rely on nologin as your only warning path. Pair scheduled shutdowns with wall or a shutdown / --when= message so users hear about maintenance before logins are refused.

Schedule a Reboot

Maintenance that needs a new kernel or a full driver reload uses reboot scheduling.

sudo shutdown -r +10 "Reboot for kernel update"

Sample output:

Reboot scheduled for Sat 2026-08-08 10:33:13 IST, use 'shutdown -c' to cancel.

shutdown --show reads the same pending job.

sudo shutdown --show

Sample output:

Reboot scheduled for Sat 2026-08-08 10:33:13 IST, use 'shutdown -c' to cancel.

Use reboot scheduling when applications tolerate a full restart but you need a coordinated wall message and a cancellable timer. Use immediate systemctl reboot only when the host is already isolated.

Cancel a Scheduled Shutdown

When maintenance finishes early or a blocker appears, cancel before the timer fires. Either front end clears the same systemd shutdown queue.

sudo shutdown -c

sudo systemctl reboot --when=cancel

Both commands exit silently on success. Confirm the queue is empty with either show command:

sudo shutdown --show

Sample output:

No scheduled shutdown.

journald records the cancellation on the current boot.

journalctl -b 0 -n 3 --no-pager

Sample output:

Aug 08 10:23:13 vm1.lab.example systemd-logind[1108]: System shutdown has been cancelled
Aug 08 10:23:13 vm1.lab.example chronyd[1095]: System clock was stepped by 0.000000 seconds
Aug 08 10:23:59 vm1.lab.example systemd[1]: systemd-hostnamed.service: Deactivated successfully.

If you already warned users, send a short wall message so nobody logs out unnecessarily.

Notify Logged-In Users Before Maintenance

Wall broadcasts to every open terminal on the local system. Combine it with who so you know which sessions exist.

who

Sample output:

root     pts/0        2026-08-07 22:47 (10.0.2.2)

Each line is a login session. Remote administrators show with their source address in parentheses.

sudo wall "Kernel update in 15 minutes. Please save work."

Wall itself prints nothing on success. Scheduled shutdown also emits timed warnings when WARN_WALL=1 is set in the scheduled file.

Pair wall with a scheduled shutdown so the message and the clock stay aligned:

sudo shutdown -r +15 "Kernel update at scheduled time"

Users see both the immediate schedule line and repeating warnings as the deadline nears.

Check When the System Last Booted

Four read-only tools answer “when did this boot start?” with different granularity.

uptime shows how long the kernel has been running and is the fastest sanity check after you reconnect.

uptime

Sample output:

14:46:54 up 16:04,  5 users,  load average: 2.42, 2.50, 1.58

The up field is the elapsed time since this kernel started.

who -b prints only the last boot timestamp.

who -b

Sample output:

system boot  2026-08-07 22:42

last reboot reads /var/log/wtmp. On this lab host several historical rows show still running even though only one boot is live—treat that as incomplete wtmp accounting, not multiple concurrent boots.

last reboot | head -5

Sample output:

reboot   system boot  6.12.0-211.42.1. Fri Aug  7 22:42   still running
reboot   system boot  6.12.0-211.42.1. Fri Aug  7 20:30   still running
reboot   system boot  6.12.0-211.42.1. Tue Aug  4 10:08   still running
reboot   system boot  6.12.0-211.42.1. Mon Aug  3 12:56   still running
reboot   system boot  6.12.0-211.42.1. Mon Aug  3 11:49   still running

When wtmp is healthy, only the top row shows still running and older reboots include end times.

journalctl --list-boots pairs each boot with a BOOT ID for log filtering.

journalctl --list-boots

Sample output:

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
 -1 9f7766a5638b4fa2b7c56ca5418e5ee3 Fri 2026-08-07 20:30:53 IST Fri 2026-08-07 22:54:17 IST
  0 9fad3bfd56e8430eb089220e9f9860e4 Fri 2026-08-07 22:42:48 IST Sat 2026-08-08 14:46:54 IST

Boot 0 is the current session. Here boot -1 appears to end after boot 0 begins—a clock step during the prior shutdown can produce that overlap. Compare who -b and a new BOOT ID at index 0 after you reconnect from a maintenance reboot.

Inspect Shutdown and Reboot Logs

journald keeps boot-scoped journals. Filter by boot ID instead of scrolling an entire file.

View the tail of the previous boot:

journalctl -b -1 -n 5 --no-pager

Sample output:

Aug 07 22:53:28 vm1.lab.example chronyd[10265]: System clock was stepped by 0.000000 seconds
Aug 07 22:53:49 vm1.lab.example systemd[1]: systemd-hostnamed.service: Deactivated successfully.
Aug 07 22:54:17 vm1.lab.example sudo[34167]:     root : PWD=/root/golinuxcloud-static ; USER=root ; COMMAND=/sbin/sshd -T ...
Aug 07 22:54:17 vm1.lab.example sudo[34167]: pam_unix(sudo:session): session opened for user root(uid=0) by root(uid=0)
Aug 07 22:54:17 vm1.lab.example sudo[34167]: pam_unix(sudo:session): session closed for user root

Search for shutdown or reboot markers on the current boot:

journalctl -b 0 --no-pager | grep -E 'shutdown|reboot|Stopped target' | tail -5

Unexpected reboots often leave short gaps in the previous boot’s last entries followed by a fresh system boot line in last reboot. For deeper journal filtering patterns, see journalctl filters.

last -x shutdown reboot focuses wtmp on power events when you want a quick table without JSON fields.

last -x shutdown reboot | head -5

This article stops at locating evidence, not at full crash-dump analysis.

Reboot When Connected Over SSH

SSH survives until the network stack or sshd stops. Practical effects:

• The shell may print Connection closed or hang until TCP times out.
• systemctl reboot returning is normal; shutdown continues asynchronously.
• Automation should use shutdown -r +N or systemctl reboot --when=+N with monitoring from another host, not wait on the same SSH channel.

Workflow: schedule or trigger reboot, expect the session to die, poll from a bastion with ping or ssh, then verify.

ssh admin@server 'sudo shutdown -r +5 "Short maintenance"'

After five minutes, open a new session and compare boot ID or who -b to the pre-maintenance value. If the host never returns, inspect the hypervisor console or out-of-band management—not the old SSH window.

Common Shutdown and Reboot Problems

Practical Examples

Walk through a cancellable maintenance window without touching production traffic on the final reboot step.

Check who is logged in before you announce work.

who

Broadcast the window.

sudo wall "Reboot in 15 minutes for kernel update"

Schedule the reboot with a matching message.

sudo shutdown -r +15 "Kernel update"

Sample output:

Reboot scheduled for Sat 2026-08-08 10:40:47 IST, use 'shutdown -c' to cancel.

Read the same line from shutdown --show when you want a second confirmation.

sudo shutdown --show

Sample output:

Reboot scheduled for Sat 2026-08-08 10:40:47 IST, use 'shutdown -c' to cancel.

Cancel when the change window slips. The command exits silently when cancellation succeeds.

sudo shutdown -c

Confirm the queue is empty before you tell users the event is off.

sudo shutdown --show

Sample output:

No scheduled shutdown.

Schedule again when ready—here with systemctl and a thirty-minute window:

sudo systemctl reboot --when="+30min"

Sample output:

Reboot scheduled for Sat 2026-08-08 15:17:35 IST, use 'systemctl reboot --when=cancel' to cancel.

Let that window run on a maintenance host, or cancel it on a lab VM:

sudo systemctl reboot --when=cancel

Before maintenance, capture a baseline so you can compare after reconnect:

journalctl --list-boots

Sample output:

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
 -1 9f7766a5638b4fa2b7c56ca5418e5ee3 Fri 2026-08-07 20:30:53 IST Fri 2026-08-07 22:54:17 IST
  0 9fad3bfd56e8430eb089220e9f9860e4 Fri 2026-08-07 22:42:48 IST Sat 2026-08-08 14:46:54 IST

who -b

Sample output:

system boot  2026-08-07 22:42

After the host actually reboots and you SSH back in, run the same two commands. A new index 0 BOOT ID and a system boot time later than your baseline confirm the cycle finished. Compare systemctl is-active on critical units before you close the ticket.

References

• systemd-systemctl(1) — systemctl verbs including reboot, poweroff, and halt
• shutdown(8) — timed shutdown syntax
• wall(1) — write to all users
• journalctl(1) — boot-scoped journal browsing
• Red Hat — Shutting down, suspending, and hibernating the system — RHEL 10 systemctl poweroff, halt, reboot, and --when= scheduling

Summary

You can bring a Linux host down or back up through systemctl verbs and the shutdown front end, both feeding the same systemd shutdown queue. Immediate work uses systemctl reboot, poweroff, and halt; scheduled work can use shutdown -r +15 or systemctl reboot --when="+15min", with matching --show and cancel paths on either interface.

Scheduling is where most production mistakes appear. A job left in /run/systemd/shutdown/scheduled will still fire unless someone runs shutdown -c or systemctl reboot --when=cancel, and users only know if you wall them or attach a message to the schedule. On RHEL 10, /run/nologin appears five minutes before the deadline—absence of that file right after you schedule +20 is expected, not proof that logins will stay open indefinitely.

Verification belongs in a fresh SSH session after the old one dies. uptime, who -b, last reboot, and journalctl --list-boots each answer “did we boot?” at a different level of detail; the current boot's FIRST ENTRY should follow the previous boot's LAST ENTRY when journal timestamps are consistent. Distinguish systemctl restart on one unit from a full OS reboot when services misbehave after maintenance.

For broader systemd administration, continue with the systemctl and journalctl guides linked above when you need unit control or deeper log queries. Boot target changes and bootloader recovery stay outside this power-state guide by design.