Module 2: Operate Running Systems

RHCSA domain covered: Operate Running Systems (3).

Lab in this kit: Lab 10 (GRUB, default target, recovery).

This domain is about taking a system from any state — including "won't boot" — to production-running, and reading the logs to understand what it's doing. The exam will hide a recovery scenario in here (most famously, resetting a root password you don't know), so the skills below aren't academic. You need to be able to interrupt the bootloader, drop to an emergency shell, and bring the machine back, calmly, under the clock.

Boot targets

What it is: a *target* is systemd's grouping of services that defines a system state — multi-user.target is the normal text-mode server state, graphical.target adds a GUI, rescue.target is single-user maintenance mode.

Why it matters: the exam may ask you to change what the system boots into, and the difference between "now" and "persistently" is a scored detail.

systemctl get-default                        # what the system boots into
systemctl set-default multi-user.target      # change the PERSISTENT default
systemctl isolate rescue.target              # switch state NOW, without rebooting
systemctl list-units --type=target           # what targets are active

The trap is the difference between set-default and isolate. set-default changes what happens at *next boot* and survives reboots — that's what you want when a task says "configure the system to boot into…". isolate switches the running system to a different target *right now* but doesn't persist — useful for dropping into rescue mode to fix something, useless if the task wants a permanent change. Reading the verb in the task ("boot into" = persistent; "switch to" = maybe runtime) tells you which one to use.

Reading the journal

What it is: journalctl queries the systemd journal — the unified, structured log of everything the system and its services emit.

Why it matters: when a service won't start or the boot misbehaves, the journal is where the answer is. Knowing how to *filter* it is the difference between finding the error and scrolling forever.

journalctl -u httpd                          # only this service's logs
journalctl -b                                # only this boot
journalctl -b -1                             # the PREVIOUS boot (diagnose a crash)
journalctl -b -p err                         # only error-priority messages this boot
journalctl --since '10 min ago' -f           # recent + follow live

Unfiltered, journalctl dumps the entire history and you'll never find anything. The filters compose: -u <unit> scopes to one service, -b scopes to the current boot (-b -1 to the one before, which is how you investigate a crash that's since rebooted), and -p err keeps only error-level and worse. The combination journalctl -b -p err is the fastest triage command in the kit — "show me everything that went wrong this boot." Add -f to any query to tail it live, like tail -f for the whole system.

Inspecting processes

What it is: ps is a point-in-time snapshot of running processes; sorting it surfaces what's consuming resources.

Why it matters: "find the process eating all the CPU/memory and deal with it" is a realistic task, and the sort flags make it instant.

ps -ef                                       # every process, full detail
ps aux --sort=-%cpu | head                   # top CPU consumers
ps aux --sort=-%mem | head                   # top memory consumers

The --sort=-%cpu means "sort by CPU descending" (the leading - is the descending sign), so head then shows the worst offenders first. Swap in -%mem for memory. This beats staring at top when you just need the answer to "what's the heaviest process" and want to script or screenshot it.

Root password recovery (rehearse this until it's reflex)

What it is: the supported procedure for resetting a root password you don't know, by interrupting the bootloader and editing the kernel command line.

Why it matters: it's a classic exam task, and every step has a reason — skip one and you either don't get in or you break login on the next reboot.

At the GRUB menu:

1. Highlight the kernel entry, press e to edit.
2. On the linux line, append: rd.break enforcing=0
3. Ctrl-x to boot — you land in the dracut emergency shell, before the real root is fully up.
4. Remount the real root read-write: mount -o remount,rw /sysroot
5. Switch into it: chroot /sysroot
6. Set the new password: passwd root
7. Schedule an SELinux relabel: touch /.autorelabel
8. exit twice — the system finishes booting, relabels, and reboots.

Here's the *why* behind each odd step. rd.break stops the boot in the initramfs (dracut) phase, where the real filesystem is mounted read-only at /sysroot — so you remount,rw to make it writable and chroot to act as if it's the real root. The non-obvious step is touch /.autorelabel: changing the password rewrites /etc/shadow, and a file written in this early environment gets the *wrong* SELinux context. If you skip the relabel, SELinux blocks access to /etc/shadow on the next boot and password logins (including sshd) silently fail — so you "fixed" the password but locked everyone out anyway. The enforcing=0 on the kernel line is a belt-and-suspenders move that boots permissive once so the relabel can complete cleanly.

The Lab 10 grader expects a /root/RECOVERY-NOTES.txt describing this procedure in your own words — writing it out is how it sticks.

Common pitfalls

• Forgetting touch /.autorelabel after a recovery → /etc/shadow has a stale SELinux context and password logins fail after reboot. The single most common way to "fix" a password and still fail the task.
• Using systemctl isolate when the task wanted a persistent change → it works now but reverts at reboot. Use set-default for "boot into."
• Running journalctl with no filters → you scroll forever. Always bound it with -u, -b, -p, or --since.
• Missing the GRUB edit window → the menu pauses only briefly. Be ready to hit a key the moment it appears.

Exam tips

• The exam VMs give you a short pause at the GRUB menu — watch for it and press a key immediately; you can't recover the window once it boots past.
• journalctl -b -p err is your go-to triage when a service refuses to start — it shows just this boot's errors with no noise.
• After any recovery boot, *reboot again and verify the fix survived* before moving on. The exam grades the post-reboot state.

Next: Module 3 — Local storage configuration.