RHEL 10 uses systemd to manage services, system state, dependencies, mounts, timers, sockets, and much of the boot process. Troubleshooting therefore becomes much faster when administrators read systemd state and the journal as one connected story instead of restarting services repeatedly and hoping the error disappears.<\/p>\n
These skills are central to the current RHCSA EX200<\/a> scope and the wider Red Hat certifications<\/a> path. The essential tools are A systemd unit represents a system resource. Service units manage daemons and processes, target units group units into system states, mount units represent file-system mounts, timer units schedule activation, socket units can activate services, and several other unit types participate in dependency graphs.<\/p>\n This matters because a failed service may actually be waiting on a mount, socket, device, or prerequisite service. Looking only at the daemon process can miss the dependency that prevented it from starting.<\/p>\n Use If a unit failed, use Always read the exact unit name. A package can install several related services, sockets, and timers, and troubleshooting the wrong unit leads to misleading conclusions.<\/p>\n Previous-boot logs are particularly valuable for crashes and boot failures because the system may be healthy by the time you log in again. Persistent journal configuration and retention therefore affect how much historical evidence is available.<\/p>\n Read context around the first failure, not only the final repeated error. Later messages often describe consequences, while the earliest error reveals the actual cause such as a missing file, permission problem, failed dependency, or invalid configuration.<\/p>\n When a service \u201cdoes not start after reboot,\u201d first determine whether it was enabled and which target wants it. When a service \u201cwill not start now,\u201d focus on runtime status, configuration, dependencies, permissions, and journal messages.<\/p>\n Using Systemd unit files can express dependency relationships such as This distinction explains many custom unit mistakes. An administrator adds Package-provided unit files normally live under Targets group related units and act as synchronization points. RHEL 10 documentation describes using rescue and emergency targets for recovery. Emergency mode is intentionally minimal and is useful when normal boot cannot complete. Administrators can also select a different target for one boot by changing the kernel command line with a systemctl<\/code> for unit state and control and journalctl<\/code> for time-ordered diagnostic evidence.<\/p>\nThink in units, not only services<\/h2>\n
systemctl list-units<\/code> to see loaded runtime units and systemctl list-unit-files<\/code> to inspect installed enablement state. The distinction between a unit being loaded, active, enabled, or failed is fundamental to diagnosis.<\/p>\nStart with systemctl status, then go deeper<\/h2>\n
systemctl status name.service<\/code> gives a compact first view: load state, active state, main process information, recent log lines, and failure reason when available. It is a triage command, not the complete investigation.<\/p>\nsystemctl --failed<\/code> to see whether related units also failed. systemctl cat<\/code> shows the vendor unit plus overrides and drop-ins, which is often the fastest way to discover that local customization changed startup behavior. systemctl show<\/code> exposes detailed properties for deeper analysis.<\/p>\nThe journal lets you narrow evidence by boot, unit, time, and priority<\/h2>\n
journalctl -b<\/code> displays messages from the current boot. Filtering with -u name.service<\/code> narrows output to a unit, while -p err<\/code> focuses on errors and higher priorities. Time filters such as --since<\/code> and --until<\/code> are useful when an operator knows when the incident began.<\/p>\nEnablement and runtime state answer different questions<\/h2>\n
systemctl start<\/code> activates a unit now. systemctl enable<\/code> configures it to participate in future boot or target activation according to the unit’s install metadata. A service can therefore be running but disabled, or enabled but currently stopped.<\/p>\nsystemctl is-enabled<\/code> and systemctl is-active<\/code> makes that distinction explicit and works well in scripts and troubleshooting checklists.<\/p>\nDependencies and ordering are not the same thing<\/h2>\n
Wants<\/code> and Requires<\/code>, and ordering relationships such as After<\/code> and Before<\/code>. Saying that one unit starts after another does not necessarily cause the other unit to be started; ordering and requirement are separate concepts.<\/p>\nAfter=network.target<\/code> expecting it to guarantee a fully usable network dependency, or adds a requirement without the intended ordering. Read both the dependency and ordering directives when troubleshooting startup sequence.<\/p>\nsystemctl list-dependencies<\/code> and unit-file inspection help reveal the relationship graph. For boot performance or ordering issues, systemd analysis tools can identify which units delayed the path to the target state.<\/p>\nUse drop-ins instead of editing vendor unit files<\/h2>\n
\/usr\/lib\/systemd\/system<\/code>. Administrator overrides belong under \/etc\/systemd\/system<\/code>, commonly as drop-in configuration. Editing the vendor file directly risks losing local changes during package updates and makes configuration history harder to understand.<\/p>\nsystemctl edit name.service<\/code> provides a controlled way to create an override. After creating or modifying unit files, run systemctl daemon-reload<\/code> so systemd reloads definitions and rebuilds its dependency view. If the service is running and the changed directives require it, restart the unit after reloading.<\/p>\nsystemctl cat<\/code> is valuable because it shows the effective unit sources together, helping administrators see both vendor defaults and local customization.<\/p>\nTargets define system states and recovery modes<\/h2>\n
multi-user.target<\/code> represents a common non-graphical multi-user state, while other targets represent graphical startup, rescue, emergency, or shutdown states.<\/p>\nsystemd.unit=<\/code> target.<\/p>\n