Boot, Reboot, and
Shut Down a System

Boot, reboot, and shut down a system normally

CIS126RH | RHEL System Administration 1
Mesa Community College

Controlling the power state of a Linux system is a fundamental administrative skill. Every server eventually needs maintenance that requires a reboot, and every system must be shut down cleanly to prevent data corruption and filesystem damage. This module covers the systemd tools for initiating and scheduling shutdowns and reboots, how to communicate with logged-in users, and what happens at each stage of the boot and shutdown process. These operations are tested on the RHCSA exam.

Learning Objectives

  1. Shut down and power off a system — Use systemctl poweroff and shutdown to cleanly stop all services and power off the machine
  2. Reboot a system — Use systemctl reboot and shutdown -r to restart the system after applying updates or configuration changes
  3. Schedule shutdowns and notify users — Use the shutdown command with a time argument to schedule a maintenance window and broadcast a wall message to logged-in users
  4. Explain what happens during a clean shutdown — Describe the systemd shutdown sequence: service stop order, filesystem unmounting, and the final power state

systemd Power Management Commands

On RHEL 9, power state changes are managed by systemd through systemctl. Each command transitions the system to a specific target.

Command Target What it does
systemctl poweroff poweroff.target Stop all services, unmount filesystems, power off the machine
systemctl reboot reboot.target Stop all services, unmount filesystems, restart the machine
systemctl halt halt.target Stop all services and halt the CPU — does not power off
systemctl suspend suspend.target Suspend to RAM — preserves state, cuts most power
systemctl hibernate hibernate.target Write RAM to disk and power off — full state preservation
halt vs poweroff

systemctl halt stops the OS but leaves the hardware running — the machine stays on and must be powered off manually. Always use systemctl poweroff when you want the machine to turn off.

Immediate Shutdown and Reboot

These commands take effect immediately — all logged-in users are disconnected without warning.

# Power off the system immediately
$ sudo systemctl poweroff

# Reboot the system immediately
$ sudo systemctl reboot

# Halt (stop OS but do not power off)
$ sudo systemctl halt

# Traditional commands still work — they call systemctl internally
$ sudo poweroff
$ sudo reboot
$ sudo halt

# shutdown with -h now is equivalent to poweroff
$ sudo shutdown -h now

# shutdown with -r now is equivalent to reboot
$ sudo shutdown -r now
All of these require root or sudo

Power state changes affect all users on the system. They require root privilege. On a system where student has full sudo rights, prefix each command with sudo.

The shutdown Command

shutdown is the preferred tool when you need to schedule a maintenance window, cancel a pending shutdown, or send a message to logged-in users.

# Shut down in 10 minutes with a message to all users
$ sudo shutdown -h +10 "System going down for maintenance"
Shutdown scheduled for Mon 2026-05-25 10:30:00 MST, use 'shutdown -c' to cancel.

# Reboot in 5 minutes with a message
$ sudo shutdown -r +5 "Rebooting to apply kernel update"

# Shut down at a specific time (24-hour format)
$ sudo shutdown -h 23:00 "Nightly maintenance window"

# Cancel a pending shutdown
$ sudo shutdown -c
Shutdown has been cancelled.

# Immediate shutdown (now = +0)
$ sudo shutdown -h now
RHCSA Focus

Know the shutdown time formats: now, +N (minutes from now), and HH:MM (absolute time). Know -h for halt/poweroff and -r for reboot. Know -c to cancel.

Wall Messages: Notifying Logged-In Users

A wall message (write all) is broadcast to every logged-in user's terminal. Shutdown schedules and admin notifications use wall to communicate maintenance windows.

# Send a wall message to all logged-in users manually
$ wall "Server going down at 23:00 for disk maintenance"

# What users see on their terminals
Broadcast message from root@servera (pts/0) (Mon May 25 22:45:00 2026):

Server going down at 23:00 for disk maintenance

# shutdown broadcasts its message automatically
$ sudo shutdown -h +15 "Maintenance: please save your work"
# All users see this message on their terminals

# View currently logged-in users who will receive the message
$ who
Countdown warnings

When a shutdown is scheduled more than 5 minutes out, the system automatically broadcasts wall messages at decreasing intervals: 60, 30, 15, 10, 5, 4, 3, 2, and 1 minute before the scheduled time. Users have time to save their work.

Checking Uptime and Boot History

Before scheduling a reboot, confirm how long the system has been running and review recent boot events.

# How long has the system been running?
$ uptime
 10:45:00 up 14 days, 3:22, 2 users, load average: 0.01, 0.03, 0.00

$ uptime -p
up 14 days, 3 hours, 22 minutes

# Show recent boot and shutdown events
$ last reboot
reboot   system boot  5.14.0-362.el9  Mon May 11 07:23   still running
reboot   system boot  5.14.0-362.el9  Sun Apr 27 14:00 - 07:22 (13+17:22)

# Show the current boot time from systemd
$ systemctl show --value --property GeneratorsStartTimestamp

# Show time spent in each boot phase
$ systemd-analyze
Check uptime before scheduling maintenance

Check uptime and last reboot before a maintenance window to confirm when the system was last rebooted and build a record of reboot history for change management documentation.

The Clean Shutdown Sequence

When you run systemctl poweroff or shutdown -h now, systemd executes a precise sequence to shut down the system safely.

  1. Broadcast wall message — logged-in users are notified
  2. Block new logins — the system stops accepting new connections
  3. Send SIGTERM to all processes — services have time to finish cleanly
  4. Stop systemd units in reverse order — services stop in the reverse of their start order; dependencies are respected
  5. Unmount filesystems — all data is flushed to disk and filesystems are unmounted cleanly
  6. Remount root read-only — the root filesystem is made read-only as a final safety measure
  7. Final power action — the hardware is powered off, rebooted, or halted as requested
Never hard-power-off a running system

Pulling the power cord or pressing the hardware power button without a clean shutdown can corrupt filesystems, leave databases in an inconsistent state, and cause data loss. Always use systemctl poweroff or shutdown -h now.

The Boot Process Overview

Understanding what happens during a normal boot helps administrators diagnose problems and understand why a reboot is sometimes required.

  1. BIOS/UEFI — firmware initializes hardware and locates the bootloader
  2. GRUB2 — the bootloader loads the kernel and initramfs into memory
  3. Kernel initialization — the kernel detects hardware, mounts the initramfs, and starts the init process
  4. systemd (PID 1) — the first real process; reads its unit files and starts activating the default target
  5. Target activation — systemd starts all units required by the default target in dependency order
  6. Login prompt — multi-user.target is reached and the getty service presents a login prompt
Why reboots are sometimes required

A kernel update installs a new kernel file but the running kernel cannot be replaced in memory. A reboot is required to start running the new kernel. Similarly, some low-level system library updates (like glibc) require a reboot for all services to pick up the new version.

Checking if a Reboot is Needed

After applying updates, use these commands to determine whether a reboot is required before the changes take effect.

# Check if any installed updates require a reboot
$ needs-restarting -r
Core libraries or services have been updated since boot-up:
  kernel
Reboot is required to fully utilize these updates.

# List services using outdated libraries (need restart, not reboot)
$ sudo needs-restarting
1234 : /usr/sbin/httpd
5678 : /usr/sbin/sshd

# Check the installed kernel vs the running kernel
$ uname -r
5.14.0-362.8.1.el9.x86_64
$ rpm -q kernel | tail -1
kernel-5.14.0-427.13.1.el9.x86_64
# Running and installed kernels differ — reboot needed
needs-restarting package

needs-restarting is provided by the dnf-utils package. Install it with sudo dnf install dnf-utils if the command is not found.

Scheduling Maintenance Windows

Professional maintenance procedures communicate with users, log the event, and leave a documented trail.

Planned maintenance workflow

  1. Check who is logged in: who or w
  2. Send advance notice: wall "Maintenance reboot in 30 minutes"
  3. Schedule the shutdown: sudo shutdown -r +30 "Scheduled maintenance"
  4. Confirm the schedule is set (the command prints the scheduled time)
  5. Log the maintenance in your change management system
  6. If plans change: sudo shutdown -c cancels it

Emergency immediate reboot

# When immediate action is required
$ wall "EMERGENCY: system rebooting now for critical patch"
$ sudo systemctl reboot
Always communicate before rebooting

Even on servers without interactive users, a wall message creates an audit trail and alerts anyone monitoring terminals or log files that a planned action is underway.

Emergency and Recovery States

In addition to normal shutdown and reboot, systemd provides special targets for recovery situations.

Target How to reach it When to use
rescue.target sudo systemctl isolate rescue.target Single-user maintenance mode — most services stopped, root shell only
emergency.target At boot: append systemd.unit=emergency.target to kernel line Minimal environment — root filesystem mounted read-only, almost nothing running
multi-user.target sudo systemctl isolate multi-user.target Return to normal multi-user mode from rescue 
# Enter rescue mode (requires root password)
$ sudo systemctl isolate rescue.target

# Return to normal operation from rescue mode
rescue:~# systemctl default
# or
rescue:~# systemctl isolate multi-user.target

systemd-analyze: Boot Performance

systemd-analyze reports how long the boot process took and identifies services that slow down startup — useful after a reboot to verify performance.

# Show total boot time broken into phases
$ systemd-analyze
Startup finished in 1.523s (kernel) + 2.841s (initrd) + 8.312s (userspace) = 12.676s
graphical.target reached after 8.290s in userspace.

# Show the slowest services to start
$ systemd-analyze blame
3.121s kdump.service
1.204s NetworkManager-wait-online.service
 .834s firewalld.service

# Generate a graphical SVG of the boot timeline
$ systemd-analyze plot > /tmp/boot-timeline.svg

# Check for potential boot cycle issues
$ systemd-analyze critical-chain
Use after every kernel update

Running systemd-analyze after a reboot confirms the system came up cleanly and identifies whether the new kernel or any updated services changed the boot time significantly.

Login Messages

Administrators can display messages to users when they log in — important for communicating planned maintenance, acceptable use policies, or system status.

/etc/motd — Message of the Day

# /etc/motd is shown to every user after a successful login
$ sudo vim /etc/motd
# Example content:
==================================================
 Authorized users only. All activity is monitored.
 Maintenance window: Sunday 23:00–01:00 MST
==================================================

/etc/issue — Pre-Login Banner

# /etc/issue is displayed before the login prompt on the console
$ cat /etc/issue
Red Hat Enterprise Linux 9.4 (Plow)
Kernel \r on an \m
Dynamic motd with systemd

Scripts in /etc/update-motd.d/ run at login time to generate a dynamic message of the day — showing current uptime, disk usage, or pending updates.

Shutdown Command Quick Reference

Goal Command
Power off immediatelysudo systemctl poweroff or sudo shutdown -h now
Reboot immediatelysudo systemctl reboot or sudo shutdown -r now
Halt (no power off)sudo systemctl halt
Power off in N minutessudo shutdown -h +N "message"
Reboot in N minutessudo shutdown -r +N "message"
Power off at HH:MMsudo shutdown -h HH:MM "message"
Cancel a pending shutdownsudo shutdown -c
Send a wall messagewall "message to all users"
Check uptimeuptime -p
Review reboot historylast reboot
Check if reboot requiredneeds-restarting -r
Analyze boot timesystemd-analyze blame

Common Mistakes

Mistake What goes wrong Correct approach
Using halt when poweroff was intended System stops the OS but stays powered on — requires manual power button press Use systemctl poweroff or shutdown -h now
Rebooting without warning users Other users lose unsaved work; SSH sessions are terminated without notice Use wall or shutdown +N "message" to give advance notice
Forgetting sudo Permission denied — power state changes require root Prefix all power commands with sudo
Hard-powering off a running system Filesystem corruption, dirty journal, database inconsistency Always use a clean shutdown command — only use hardware power button as a last resort
Rebooting without verifying the reboot is needed Unnecessary downtime when only a service restart was required Run needs-restarting -r first to confirm a reboot is actually required
Cancelling a scheduled shutdown without notifying users Users prepared for a reboot are confused when it does not happen Send a wall message when cancelling: wall "Shutdown cancelled"

Knowledge Check

Answer these before moving to the next slide.

  1. Write the command to power off a RHEL system immediately.
  2. Write the command to schedule a reboot in 20 minutes with the message "Applying kernel update — please save your work."
  3. What is the difference between systemctl halt and systemctl poweroff?
  4. A reboot has been scheduled but the maintenance window has been postponed. Write the command to cancel the pending shutdown, and what should you do immediately after cancelling it?
  5. What command tells you how long the system has been running?
  6. After installing a kernel update, how do you confirm a reboot is required before the update takes effect?

Knowledge Check — Answers

  1. sudo systemctl poweroff or equivalently sudo shutdown -h now
  2. sudo shutdown -r +20 "Applying kernel update — please save your work"
  3. systemctl halt stops all services, unmounts filesystems, and halts the CPU — but does not send the hardware power-off signal. The machine stays powered on. systemctl poweroff does everything halt does and then sends the ACPI signal to actually turn off the hardware.
  4. Cancel with: sudo shutdown -c
    Immediately after: send a wall message to inform users the shutdown is cancelled: wall "Maintenance postponed — shutdown cancelled"
  5. uptime or uptime -p for a human-readable format
  6. Run needs-restarting -r — if it reports that the kernel has been updated since the last boot, a reboot is required. Alternatively, compare the running kernel with uname -r against the installed kernel with rpm -q kernel. If they differ, a reboot is needed.

Key Takeaways

  1. Use systemctl poweroff and systemctl reboot for immediate operations. halt stops the OS but does not turn off the hardware. All power state changes require sudo.
  2. Use shutdown for scheduled maintenance. shutdown -h +N "message" schedules a poweroff. shutdown -r +N "message" schedules a reboot. shutdown -c cancels a pending shutdown.
  3. Communicate with users before rebooting. Use wall "message" for immediate notifications. Use shutdown +N "message" for automatic countdown warnings. Check who is logged in first with who.
  4. Verify a reboot is actually needed before doing it. Use needs-restarting -r after updates. Compare uname -r against rpm -q kernel. After rebooting, use systemd-analyze to confirm the system came up cleanly.

Graded Lab

  • Run uptime -p and last reboot to document the current uptime and last boot time of your lab system.
  • Send a wall message to all logged-in users announcing a maintenance window in 10 minutes.
  • Schedule a reboot in 10 minutes with the message "Lab reboot — save your work." Confirm the output shows the scheduled time.
  • Cancel the pending reboot with shutdown -c. Immediately send a wall message informing users the reboot has been cancelled.
  • Install or update a package, then run needs-restarting -r to determine whether a reboot is required. Document what it reports.
  • Reboot the system immediately with sudo systemctl reboot. After it comes back up, run systemd-analyze blame and identify the three slowest services to start.
RHCSA Objective

"Boot, reboot, and shut down a system normally." The exam tests the correct command for each power state, the correct shutdown syntax for scheduled operations, and the use of wall messages for user communication.

Next: Boot systems into different target manually