8.1 Boot, Reboot, and Shut Down a System Normally

8.1 Boot, Reboot, and Shut Down a System Normally

Quick Answer: On RHEL 10, reboot with systemctl reboot, power off with systemctl poweroff, and halt with systemctl halt. These perform orderly transitions through systemd. A normal boot ends in the configured default target (often multi-user.target or graphical.target). Prefer graceful commands over pulling virtual power—EX200 grades post-reboot state, so clean restarts matter.

Why this skill is on EX200

Official study points under Operate running systems include boot, reboot, and shut down a system normally. Performance exams constantly imply reboot: enable a service, write /etc/fstab, change network config, set a default target—then prove it still works after restart. You must:

1. Understand what “normal boot” means on a systemd RHEL system.
2. Restart or power off cleanly so units stop and filesystems unmount correctly.
3. Know the modern systemctl verbs and the classic command names still present on the box.

This section is operational hygiene. Later sections cover targets, recovery, and bootloader work; here the focus is everyday power control.

High-level boot sequence (normal path)

A healthy RHEL boot roughly follows:

You do not need to memorize every unit name for this objective, but you must know that systemd is PID 1 and that “the system is up” means the default target and its dependencies reached active state.

Check the default target and recent boots:

systemctl get-default
systemctl status
who -b
last reboot | head
journalctl -b          # current boot
journalctl -b -1       # previous boot

who -b and last reboot are quick proof that a reboot occurred—useful when documenting lab work or confirming a remote host came back.

Orderly reboot and shutdown with systemctl

On RHEL 10, systemctl is the preferred control surface:

# Restart the machine (orderly)
sudo systemctl reboot

# Power off (orderly halt + power cut when hardware supports it)
sudo systemctl poweroff

# Halt the system (stop OS; power state depends on hardware/firmware)
sudo systemctl halt

# Optional: go to firmware setup on next boot when supported
sudo systemctl reboot --firmware-setup

What “orderly” means

When you request reboot/poweroff through systemd:

1. systemd broadcasts a shutdown/reboot job.
2. Services receive stop jobs according to dependencies and timeouts.
3. Processes are terminated; stubborn ones may be killed after timeouts.
4. Filesystems are remounted read-only / unmounted as designed.
5. Final sync and reboot or power-off syscall runs.

That sequence protects journals, databases, and dirty page cache better than a hard power-off. In a VM lab, “Power off” from the hypervisor without guest-initiated shutdown is closer to yanking the cord—avoid it when testing config persistence unless you are deliberately testing crash recovery.

Wall messages and delayed shutdown

Operators sometimes schedule shutdowns:

sudo shutdown -r now          # reboot now (legacy-friendly)
sudo shutdown -h now          # halt/power off now
sudo shutdown -r +5 "Reboot in 5 minutes"
sudo shutdown -c             # cancel a pending shutdown

On systemd systems, shutdown, reboot, and poweroff binaries typically delegate into systemd. You can use either style; many Red Hat docs emphasize systemctl. Know both so a task that says “reboot the system” never stalls you on syntax.

sudo reboot
sudo poweroff
sudo halt

Forced options (use carefully)

sudo systemctl reboot -f
# or older habit:
sudo reboot -f

Force flags skip parts of the graceful unit teardown. They are for stuck systems, not routine exam reboots. Prefer normal reboot first. If a unit hangs at stop, fix the unit or wait for timeout rather than building a habit of -f.

systemctl --force variants exist for poweroff/halt as well—same caution.

Multi-user context: who is logged in?

Before rebooting a shared lab host:

who
w
loginctl list-sessions

EX200 is usually a private exam environment, but the habit of checking sessions and broadcasting (wall or shutdown’s message) is professional practice. For your exam VM, the critical habit is different: save open configs, ensure systemctl enable and file edits are written to disk (sync is rarely needed if editors flushed, but do not kill the VM mid-write).

Verifying a successful reboot cycle (exam mindset)

Many tasks are only complete if state persists after reboot. Workflow:

1. Make the change (unit enable, fstab line, sysctl drop-in, network connection).
2. Validate live (systemctl is-enabled, mount, ip a, etc.).
3. systemctl reboot (or the method the environment allows).
4. Log back in; re-run the same checks.
5. Only then mark the task done in your head.

If the exam interface reboots for you, still re-verify. Graders effectively do post-reboot checks.

Useful post-boot health glances:

systemctl is-system-running
systemctl --failed
journalctl -p err -b --no-pager | head
df -h
ip -br a

systemctl is-system-running may report running, degraded (some failed units), or other states. degraded means the system booted but something failed—investigate with systemctl --failed before assuming success.

Boot messages and emergency awareness (preview)

A normal boot does not require GRUB edits or rd.break. If the machine drops to emergency/rescue because of a bad fstab or failed local-fs dependency, that is not a normal boot—you fix the root cause (covered in storage chapters and Section 8.3 recovery patterns). For this section, aim for clean configs so reboot returns you to a login prompt on the default target.

Permissions and remote reboot

Reboot/poweroff require root privileges (direct root or sudo). On SSH:

sudo systemctl reboot
# Connection drops; wait; ssh back

Do not panic when SSH dies mid-reboot—that is expected. Wait long enough for firmware + GRUB + boot before reconnecting. In nested virtualization labs, reboot can take longer than bare metal.

If you reboot the wrong host in a multi-machine lab, you waste time—always confirm hostname first:

hostnamectl
hostname

Distinguishing halt, poweroff, and reboot

On many VMs, halt and poweroff look similar in the hypervisor console (VM stops). Conceptually, reboot returns to the boot sequence; poweroff ends in powered-off hardware/VM state.

Relationship to other operate-running-systems skills

• Targets (8.2): reboot returns you to the default target unless you interrupt GRUB or isolate temporarily.
• Recovery (8.3): when normal login is impossible, you interrupt boot—not the same as normal reboot.
• Services: systemctl reboot is not a substitute for systemctl restart httpd; reboot restarts everything.
• Logs: previous boot journals remain queryable with journalctl -b -1 if journal storage is persistent (separate objective).

Common traps

1. Hard power-off from the hypervisor as a routine “reboot” — risk filesystem checks and incomplete writes.
2. Assuming reboot is non-systemd — on RHEL it is integrated; still prefer systemctl reboot in modern write-ups.
3. Changing configs but never rebooting when the skill requires persistence proof.
4. Rebooting before writing the file (editor buffer not saved).
5. Confusing systemctl restart service with machine reboot.
6. Ignoring systemctl --failed after boot and missing a unit that broke on the new config.

Exam workflow: “Make X survive reboot”

# Example pattern after enabling a service
sudo systemctl enable --now some.service
systemctl is-enabled some.service
systemctl is-active some.service
sudo systemctl reboot
# after login:
systemctl is-enabled some.service
systemctl is-active some.service

Same pattern applies to mounts, sysctl, tuned profiles, network scripts, and default targets—reboot is the honesty check.

Section checkpoint

You should describe the normal RHEL boot path to systemd’s default target, reboot and shut down cleanly with systemctl reboot / poweroff / halt (and recognize shutdown/reboot aliases), avoid unnecessary forced power loss, verify system health after restart, and treat reboot as a required proof step for persistent configuration on EX200.