Learn › RHCSA (EX200) › Deploy, Configure, Maintain

Services with systemctl

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

Get a service into the right state and keep it there across a reboot. The core exam trap: start runs a service now but does not survive a reboot, enable sets it to start at boot but does not run it now, and enable --now does both at once. Read state with the scriptable one-word queries is-enabled (boot switch) and is-active (runtime switch), or the full systemctl status header with its Loaded and Active lines. Flip runtime with start, stop, restart, reload; flip boot with enable, disable; hard-lock with mask and release with unmask. Serves EX200 deploy-configure: start and stop services and configure services to start automatically at boot.

Picture the scene. You install a web server on a fresh RHEL 10 box, you start it, you test it, the page loads. You hand off the machine and go home. That night the server reboots for a routine patch. The next morning the page is dead, and the on-call engineer is paging you because nobody can reach the site.

You did start the service. You just never told it to come back after a reboot. Starting a service and setting it to start at boot are two separate switches, and on the exam that single confusion is the most common way people lose points on an otherwise perfect task. This lesson makes those two switches, and how to check them, second nature.

The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs are from a real RHEL 10 machine (AlmaLinux 10.2). A few values, like the exact timestamp on a running service and how long it has been up, depend on when the machine last booted, so treat those as illustrative. What is stable everywhere is the SHAPE: is-enabled prints one word about boot, is-active prints one word about right now, and status prints a header whose Loaded and Active lines carry the whole story.

On RHEL 10, a service is a background program the system runs for you: a web server, the SSH login daemon, the time-sync client. The manager that starts, stops, and supervises every one of these is called systemd, and systemctl is the single command you use to talk to it. Think of systemd as the building manager and systemctl as the intercom on your desk. You do not walk down to the boiler room; you press a button and the manager acts.

Almost everything in this lesson is systemctl followed by a verb and a service name: systemctl start sshd, systemctl status chronyd. Learn the verbs and you have learned service management on RHEL.

Every real task on a Linux server eventually comes down to a service being in the right state and staying there. You install a database and it must be running now and after every reboot. You are told to shut a service off and make sure it never comes back. You inherit a machine and need to know, without guessing, whether the firewall is actually on. systemctl is the one tool that answers and controls all of that.

The exam objective is blunt about it: start and stop services, and configure services to start automatically at boot. Those are two different jobs done with two different verbs, which is exactly the trap this lesson defuses.

Here is the whole lesson in one idea. Every service has two independent switches.

The runtime switch is whether the service is running right this second. You flip it with start and stop. It takes effect immediately and it forgets everything at the next reboot.

The boot switch is whether the service starts automatically when the machine boots. You flip it with enable and disable. It changes nothing right now; it only decides what happens after the next reboot.

start does not touch the boot switch. enable does not touch the runtime switch. That is why a service you started can vanish after a reboot, and why a service you enabled is not necessarily running yet. Hold those two switches apart in your head and this whole topic stops being confusing.

Before you change anything, learn to read state. systemctl is-enabled <service> answers one question and one question only: will this service start at the next boot? It prints a single word, enabled or disabled, and that is deliberate. A one-word answer is something a script can test, so this is the query you reach for in automation and the fast way to confirm the boot switch on the exam.

Check whether the SSH daemon is set to start at boot:

systemctl is-enabled sshd

prompt: [root@servera ~]# answer: systemctl is-enabled sshd output: enabled hint: The scriptable boot-switch query is is-enabled, then the service name: systemctl is-enabled sshd

One word: enabled. That tells you sshd, the service that lets you log in over the network, is set to start automatically at every boot. If it read disabled, the machine would boot with no SSH and you could be locked out. The value of a one-word answer is that it is unambiguous and machine-readable: a script can branch on it, and you can eyeball it in a fraction of a second. This is the boot switch, and nothing about this command starts or stops anything right now.

Its twin is systemctl is-active <service>. Same one-word style, different question: is this service running right now? It prints active if the service is up, inactive if it is stopped, failed if it tried to run and crashed. Where is-enabled reads the boot switch, is-active reads the runtime switch, and keeping those two commands paired in your mind keeps the two switches paired too.

Check whether sshd is running at this moment:

systemctl is-active sshd

prompt: [root@servera ~]# answer: systemctl is-active sshd output: active hint: The scriptable runtime-switch query is is-active, then the service name: systemctl is-active sshd

active means sshd is running at this instant. Read is-enabled and is-active together and you know a service completely: enabled plus active is the healthy steady state for something like SSH, running now and set to survive a reboot. disabled plus active means it is running but will not come back after a reboot, which is exactly the web-server trap from the opening. Two one-word commands, two switches, the full picture.

is-active can print activating or deactivating for a service caught mid-transition, and failed for one that crashed on startup. Those are normal readings, not errors in the command. If you ever see failed, that is your cue to run systemctl status and read why.

The one-word commands are fast but terse. When you need the full picture, systemctl status <service> prints a header that carries everything: whether the unit is loaded, whether it is enabled at boot, whether it is running now, and since when. Two lines in that header do most of the work.

The Loaded line ends with the boot state in parentheses, enabled or disabled. The Active line begins with the runtime state, active (running) or inactive (dead), and gives the timestamp it entered that state. Read those two lines and you have both switches at a glance.

Look at the time-sync client, chronyd:

systemctl status chronyd

prompt: [root@servera ~]# answer: systemctl status chronyd output:

Read it top to bottom. The first line names the unit, chronyd.service, and describes it, NTP client/server. The Loaded line says loaded (systemd found and parsed the unit file) and then, in the parentheses, enabled: that is the boot switch, set to start at boot. The Active line says active (running): that is the runtime switch, running now, and the timestamp tells you since when. So chronyd is both enabled and active, the healthy state. The two switches you learned as one-word answers are right here in the header, spelled out with context.

Your Active: timestamp and the 5min ago will differ from what is printed here. Those depend on when the machine last booted and when chronyd last started, so they change on every machine and every boot. What stays constant is the shape: active (running) for something that is up, and a Loaded: line whose parentheses hold enabled or disabled.

Now the actions. The runtime verbs are four. start turns it on now. stop turns it off now. restart stops then starts, to load a whole new configuration. reload re-reads the config without dropping connections, when the service supports it. Reach for reload over restart when you want a config change picked up without a blip; reach for restart when the change is deep enough that a clean stop-and-start is required.

The boot verbs are enable (start it at boot from now on) and disable (do not). And the one that saves you every time: enable --now. It enables the service AND starts it in a single command, flipping both switches at once. It is the answer to almost every exam task that says get this service running and make sure it comes back after a reboot.

Enable the web server and start it in one move:

systemctl enable --now httpd

prompt: [root@servera ~]# answer: systemctl enable --now httpd output: hint: One command flips both switches: systemctl enable --now httpd

This single command flips both switches at once. The enable half records the boot switch by dropping a link into systemd's multi-user.target.wants directory, which is how it remembers to start httpd at boot. The --now half also starts the service immediately, so it is running this instant. Had you run enable alone, the boot switch would be set but the service would still be stopped until the next reboot. Had you run start alone, it would be running now but gone after a reboot. enable --now is the move that leaves nothing for a reboot to undo.

This is the single most common way to lose a point on the exam: you start a service, confirm it is running, and move on, never running enable. It passes your own eyeball test and fails the moment the grading machine reboots. Whenever a task says a service must be running, ask yourself whether it also needs to survive a reboot. If yes, and it almost always is yes, use enable --now, not bare start.

One more pair for the times you need a service to stay off no matter what. disable stops a service from starting at boot, but another package or an operator can still start it by hand or pull it in as a dependency. mask is the hard lock: it points the unit at /dev/null so the service cannot be started at all, by anyone, until you unmask it. Use it when a task says ensure this service can never run, or when two services conflict and one must be firmly out of the way.

Hard-lock a service so it cannot be started:

systemctl mask firewalld

prompt: [root@servera ~]# answer: systemctl mask firewalld output: hint: The hard-off lock is mask, then the service name: systemctl mask firewalld

Masking points the unit at /dev/null, and that link is the lock. With it in place, systemctl start firewalld will refuse, reporting the unit is masked, and nothing can pull it in as a dependency either. That is stronger than disable, which only removes the boot-time autostart and still lets someone start it by hand. To undo the lock you run systemctl unmask firewalld, which removes the link and lets the service be started again. If a masked service seems impossible to start no matter what you try, check for exactly this: someone masked it.

A masked service cannot be started even with enable --now. If you try to enable-and-start a unit and it stubbornly refuses, run systemctl status <service> and look for the word masked on the Loaded line. unmask it first, then enable and start. Forgetting a leftover mask is a quiet way to fail a task that looks like it should just work.

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

A task hands you a freshly installed service called httpd. The requirement is plain: it must be running now, and it must come back on its own after the machine reboots. You know that start alone leaves it dead after a reboot, and enable alone leaves it stopped right now. Which single systemctl command flips both switches at once, starting the service immediately and setting it to autostart at boot?

prompt: [root@servera ~]# answer: systemctl enable --now httpd output: hint: One verb, one flag: enable with --now flips both switches. systemctl enable --now httpd

systemctl enable --now httpd is the answer, and it is the answer to a large share of exam service tasks. The enable half sets the boot switch by linking the unit into multi-user.target.wants, and the --now half flips the runtime switch so the service is up this instant. One command, both requirements met, nothing left for a reboot to undo. When a task pairs the words running and boot, this is the reflex to reach for.

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

The one thing to burn in for the exam: start and enable are two different switches. start runs it now, enable makes it come back at boot, and enable --now does both. When a task says running and surviving a reboot, reach for enable --now.

For a scriptable check you never have to eyeball, pair the two one-word queries: systemctl is-enabled sshd for the boot switch and systemctl is-active sshd for the runtime switch. Together they tell you a service is both set to start at boot and running right now, which is the state the exam almost always wants.

The practice terminal has walked you through the whole loop. is-enabled and is-active read the two switches as one-word answers. status reads the full Loaded and Active header. start, stop, restart, and reload work the runtime switch. enable and disable work the boot switch. enable --now flips both at once, and mask locks a service off for good. Every one of those you typed yourself.

The deploy-configure module mission, Operation Rollout, is where you run these against a real RHEL 10 machine. A full VM boots for you with real services waiting to be brought into the right state. The mission hands you deploy-and-configure objectives that use exactly what you practiced here. Get a service running and make it survive a reboot, confirm state with the one-word queries, and lock a service off where the task demands it. One difference from this lesson: the mission shows no commands. You read the objective, recall the enable --now and is-enabled and mask forms, and type them. That recall is what makes it stick on exam day.

Finish the other deploy-configure lessons, then go run Operation Rollout and get a service into the right state for real.

Practice Services with systemctl in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.