Learn › RHCSA (EX200) › Operate Running Systems

Boot, Reboot, Shutdown

systemctl - a hands-on Linux lab on a real virtual machine.

Control services and system power with systemctl. is-active for the now, is-enabled for the boot, status for the full Loaded and Active picture, the acting verbs start stop restart reload enable, the enable --now shortcut, list-units --type=service, and the power verbs reboot / poweroff / shutdown (described, not run). Serves EX200 operate task 19: start a service and make it survive a reboot, which is exactly what the grader re-checks.

You are handed a task: make sure the time-sync service is running on this machine. You type the command to start it, you see it come alive, you move on. An hour later the grader reboots the machine and re-checks. The service is dead. You lose the points, and you never touched the machine again to know why.

Nothing you did was wrong. It was just incomplete. Starting a service turns it on for right now. It says nothing about the next boot. On RHEL, one word separates on now from on forever, and knowing which is which is EX200 operate task 19: start a service, and configure it so it survives a reboot. That single distinction is the whole lesson, and it is the one thing the grader always checks.

The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs shown are from a real RHEL 10 machine (AlmaLinux 10.2). Service names and timestamps on your own machine may differ, but the commands and the start-versus-enable logic are identical everywhere, and those are the lesson.

systemctl is the single control panel for systemd, the first program RHEL starts at boot and the manager of every service after it. A service is a background program the system runs for you, like sshd for remote logins or chronyd for keeping the clock correct. When you want a service on, off, restarted, or checked, you go through systemctl.

It also controls the machine's power state, because on systemd a reboot or a shutdown is just another thing systemd coordinates. So one command starts your services AND, when the time comes, brings the whole system down cleanly. We meet the service verbs first, then the power verbs.

Before systemd, RHEL used a scatter of separate tools: service to start things, chkconfig to make them boot, init and telinit to change run states, reboot and poweroff as their own programs. systemd folded all of them into one verb-driven command. Those old names still work on RHEL 10, but they are now thin wrappers that call systemctl underneath.

You will still see reboot and poweroff typed as bare commands in the wild, and they work. Under the hood each one just runs systemctl reboot or systemctl poweroff. Learning the systemctl form once teaches you every wrapper for free.

Start with the simplest question you can ask about a service: is it running this instant? The subcommand is is-active, and it answers with one word, active when the service is up, inactive when it is not. chronyd is the time-sync service, up on this machine.

Before you run it, decide what you expect: a healthy time service should be running, so the answer should be active.

systemctl is-active chronyd

prompt: student@servera:~$ answer: systemctl is-active chronyd output: active hint: The subcommand is is-active, then the service name: systemctl is-active chronyd

active. The service is running this instant. That is the here-and-now half of the picture: is-active reports the live state, nothing more. It does not tell you whether the service will come back after a reboot. That is a separate question, with a separate word, and it is the one that costs people points. You ask it next.

Here is the distinction the whole lesson turns on. Enabled means the service is wired to start automatically at every boot. It is completely separate from whether the service is running right now. A service can be running but not enabled (it dies at the next reboot), or enabled but stopped (it will come back on reboot). The subcommand is-enabled answers only the boot question, with enabled or disabled.

Ask whether chronyd is set to start at boot:

systemctl is-enabled chronyd

prompt: student@servera:~$ answer: systemctl is-enabled chronyd output: enabled hint: Same shape as is-active, but the boot question: systemctl is-enabled chronyd

enabled. This service is wired to start on every boot, so it will survive the grader's reboot. Put the last two answers together and you have the mental model that scores task 19: is-active said running now, is-enabled said running after reboot. Both true is the finished state. The trap in the cold open was a service that was active but disabled: alive now, gone after reboot. The fix, coming up, is one word.

The one-word answers are quick, but sometimes you want the whole story: is it running, is it enabled, when did it start, is anything wrong. systemctl status NAME prints all of it. The two lines to read first are Loaded and Active.

Look at the remote-login service, sshd:

systemctl status sshd

prompt: student@servera:~$ answer: systemctl status sshd output:

Both answers from the last two steps live in this one screen. Read the Loaded line to its end: the word enabled there is the same fact is-enabled gave you, this service starts at boot. Read the Active line: active (running) is the same fact is-active gave you, it is up now, and it even tells you since when. status is the human-readable version of both one-word checks at once, plus the recent log lines below (trimmed here). When a service misbehaves, this is the first screen you open.

Your status output will differ in the details: a different Invocation id, a different start time, more or fewer log lines at the bottom. What stays put is the shape, the Loaded line carrying enabled or disabled, and the Active line carrying active or inactive. Those two words are what you scan for.

So far you only asked questions. Now the verbs that act. Each takes a service name and needs root, so on the exam you prefix them with sudo.

Read the two halves of the table together. start and stop change the NOW. enable and disable change the BOOT. They are independent switches. This is exactly why the cold-open service died: someone ran start (now) but never enable (boot).

systemd gives you the fix in one move: sudo systemctl enable --now NAME enables the service AND starts it in a single command. Enabled plus started, both switches on, in one line. On the exam, enable --now is the habit that keeps you from ever losing task 19 to a forgotten start or a forgotten enable.

One more read command, for when you want the whole board instead of one service. systemctl list-units --type=service lists every service unit systemd knows. Add --state=running and it narrows to just the ones currently up, so you can scan the machine at a glance.

systemctl list-units --type=service --state=running

prompt: student@servera:~$ answer: systemctl list-units --type=service --state=running output: UNIT LOAD ACTIVE SUB DESCRIPTION atd.service loaded active running Deferred execution scheduler auditd.service loaded active running Security Audit Logging Service chronyd.service loaded active running NTP client/server crond.service loaded active running Command Scheduler dbus-broker.service loaded active running D-Bus System Message Bus hint: list-units, then --type=service, then --state=running to narrow to the live ones.

There is the running board. Each row is one service: the UNIT name (note the .service suffix), then LOAD, ACTIVE, and SUB columns confirming it is loaded, active, and running, then a plain-English DESCRIPTION. chronyd.service sits right there, the same service you checked one at a time. This is how you confirm a fleet of services in one screen instead of asking is-active over and over. Your list will be longer and its rows will differ by machine, but the columns are always these.

The same systemctl also brings the whole machine down, cleanly, through systemd. These are real commands you will type on the exam, but read them here, do NOT run them in the practice box: each one takes the system offline for real.

The exam reason to know these: after a persistent change (a new default target, an edited mount, a service you just enabled), the safest verification is to actually reboot and confirm the change held. A clean systemctl reboot is how you prove your work survives the very reboot the grader will perform.

Never type reboot, poweroff, or shutdown to test them in a shell you care about, and never during a lesson step. They are not reversible mid-flight the way a stopped service is. On the exam you reboot deliberately, once, to verify persistence, not to experiment. shutdown -c cancels a timed one, but a bare systemctl reboot goes immediately, with nothing to cancel.

Scaffolding off. No command is shown this time. You have every piece you need.

A task says the time-sync service chronyd must be running AND set to come back after a reboot. You have already handled the running-now part. The grader is about to reboot, so the question you must answer for yourself is the boot one: is chronyd wired to start at boot? Ask the one subcommand that reports only the boot state, and expect the word that means yes.

prompt: student@servera:~$ answer: systemctl is-enabled chronyd output: enabled hint: You want the boot question, not the now question. That subcommand is is-enabled, then the service name.

enabled. That single word is the grader's whole test for persistence: the service is wired into the boot sequence, so it will be back after the reboot. If the answer had been disabled, the one-line fix is sudo systemctl enable --now chronyd, which enables it for boot and starts it now in the same breath. That is task 19 in miniature: is-active proves it runs now, is-enabled proves it runs after reboot, and enable --now guarantees both at once.

You earned this cheat sheet. Every row is a form you just ran or read:

The one line to burn in for the exam: active is now, enabled is after reboot, and the grader checks the second one. When a task says a service must survive a reboot, sudo systemctl enable --now NAME is the answer that never loses the point.

The default boot target on RHEL 10 is multi-user.target, the full text-mode system your services run under. You can confirm it with systemctl get-default. Changing that default is a separate operate task, but it is the same systemctl, so the muscle memory you built here carries straight into it.

The practice terminal has shown you the shape of service control. You have is-active for the now, is-enabled for the boot, and status for the full Loaded and Active picture. You have the acting verbs start stop restart reload enable, the enable --now shortcut that sets both switches at once, the running-services board, and the power verbs you describe but never run. Every read command you typed yourself.

The operating-systems module mission is where you run these against a real RHEL 10 machine. A full VM boots for you, with its own services to start, enable, and verify. The mission hands you objectives that use exactly what you practiced here: bring a service up, wire it to survive a reboot, and confirm both states the way a grader would. One difference from this lesson: the mission shows no commands. You read the objective, recall the systemctl verb, and type it. That recall is what makes it stick on exam day.

Finish the other operating-systems lessons, then go make a service that comes back on its own.

Practice Boot, Reboot, Shutdown in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.