Practical systemctl Basics: Manage systemd Services Safely

When `systemctl` Confuses You (And When It Won’t Work At All)

A super common mistake: assuming every Linux server uses systemd and blindly copy-pasting systemctl commands from some blog.

If your terminal answers with something like:

bash: systemctl: command not found

systemctl: command not found

there’s a good chance your distro isn’t using systemd at all. In that case, no amount of systemctl magic will help — you’re simply on a different init system.

But if you are on a server that runs systemd (which is most modern Linux distros), learning systemctl will make your admin life a lot easier. It’s the main tool to manage services, units, and overall system state.

This guide walks you through the practical basics: checking status, understanding what’s running, and inspecting configuration — safely and step by step.

Step 1: Make Sure `systemctl` Actually Exists

Before doing anything, you need to confirm that systemd and systemctl are really there.

Open a terminal and run:

systemctl --version

If you see version info and some text about systemd, you’re good. This means your system uses systemd, and systemctl is the right tool.

If instead you see an error like:

bash: systemctl: command not found

then your machine is using a different init system, and this guide won’t apply directly. Don’t try to install systemctl manually just to “make it work” — that’s asking for trouble. Use your distro’s native tools instead.

Safety note:
– If this is a production server, always test new commands on a staging machine or non-critical VM first.
– Even status commands are safe, but once you get into changing system state, test elsewhere before you risk uptime.

Step 2: Understand What `systemctl` Is Really Managing

systemctl talks to systemd, which is both an init system and a system manager. Its main job is to:

Start the stuff that has to run after the kernel boots (services, daemons, etc.).
Manage and track those services while the system is running.

When you use systemctl, you’re dealing with units. The source text mentions that systemctl lets you “manage services, units, and overall system state” and list “loaded units and all unit files.”

In practice, the most common units you’ll care about are services (stuff like web servers, database daemons, etc.). Think of a “unit” as a thing systemd knows how to start/stop/track.

You don’t need to memorize all types to start. Just remember:
– Units = managed pieces.
– Services = the units you most often touch.

That mental model already makes systemctl less scary.

Step 3: Check Whether a Service Is Running and Healthy

Now to the part you’ll use daily: checking whether something is up or broken.

The source highlights a few super useful systemctl subcommands:

status, is-active, is-enabled, and is-failed make it easy to quickly understand whether a service is running and healthy.

Let’s walk through those.

3.1. Check full service status

Use status when you want a detailed view.

systemctl status nginx

Replace nginx with the service name you care about (like apache2, php-fpm, sshd, etc.). You’ll see:
– Whether it’s active or not.
– Recent log lines.
– Main process info.

This is usually your first stop when something “just stopped working.”

3.2. Quick check: is it running?

If you only care whether a service is running right now:

systemctl is-active nginx

You’ll get a simple answer like:
– active (good)
– inactive
– failed

This is handy in scripts or quick checks where you don’t want a wall of text.

3.3. Check if it’s enabled at boot

To see whether a service is configured to start when the system boots:

systemctl is-enabled nginx

This tells you whether systemd will try to start it automatically next time you reboot. Good when you’re troubleshooting “it works after I start it manually, but disappears after reboot.”

3.4. Check if a service has failed

Sometimes a service exists, but it died badly.

systemctl is-failed nginx

If you see failed, you know systemd thinks something went wrong. Combine this with systemctl status for more details.

These four checks already give you a clear picture of whether a service is alive, auto-started, and in a healthy state.

Step 4: List What’s Running and What’s Available

The source mentions:

systemctl lets you view both what’s currently active and what’s available on the system by listing loaded units and all unit files.

This is great when you’re not even sure what’s installed or running.

4.1. List loaded (known) units

To see what units systemd currently knows about:

systemctl list-units

This shows units that are loaded into memory. You’ll see which ones are:
– Active
– Inactive
– Failed

It’s a good “what on earth is this system doing?” overview.

4.2. List all unit files on disk

If you want to see all unit files that exist on the system, not just what’s currently active:

systemctl list-unit-files

This answers questions like:
– “Is there even a service unit for this thing?”
– “Is this service available but disabled?”

Use this when you think something should be installed but doesn’t show up in list-units.

Step 5: Inspect Configuration, Properties, and Dependencies

The source notes that:

systemd manages resources, and you can inspect their configuration, properties, and dependencies directly from the command line.

This is where systemctl becomes more than just a start/stop switch.

5.1. Why inspect properties?

When a service misbehaves, sometimes the config file isn’t the only story. You also want to know:
– What resource limits apply?
– What does it depend on?
– How is it supposed to be started?

You can inspect these directly via systemctl.

5.2. Safe inspection mindset

A quick safety reminder:
– Inspecting (viewing) properties is safe.
– Changing systemd configuration is powerful and should be done carefully.

The source explicitly suggests restarting or reloading systemd configuration afterwards if you do change things, which implies these changes matter system-wide.

So:
– Read and inspect as much as you want.
– Only edit or reload when you understand what you’re touching.

5.3. Look at dependencies conceptually

Even without the exact command spelled out in the source, we know from the description that:

systemd can show unit dependencies.
This helps you see how services relate to each other.

When troubleshooting startup order or “why won’t this start until that is up,” knowing there’s a built-in way to inspect dependencies already points you in the right direction.

Again, stick to inspection first. Don’t start ripping out dependencies or editing unit files on a production system without a backup and a way back.

Step 6: Changing System State (With Care)

The guide mentions that systemctl is used to “change system states.” That’s basically things like starting and stopping services and adjusting how the system behaves as a whole.

While the source summary doesn’t list all the exact commands, the key takeaway is:

systemctl is your central tool for controlling the init system.
It’s responsible for managing startup and shutdown behavior.

A few safety pointers when you’re working at this level:

Don’t test on production first.
If you’re experimenting with system state changes, use a test VM.
Know who you’re logged in as.
Many systemctl actions require root. Use sudo explicitly so you’re clear when you’re doing privileged actions.
Have access out-of-band if possible.
On servers (especially cloud ones), be sure you can reach the console if you accidentally stop something important.
Understand what’s being controlled.
You’re not just toggling a service; you’re interacting with the system’s core manager.

The power is nice, but respect it the way you respect a car jack: very useful, but you don’t crawl under it without thinking.

Step 7: Working With systemd Configuration Safely

The source ends with a reminder:

systemd manages resources, and you can inspect their configuration, properties, and dependencies directly from the command line.

systemd configuration afterward.

That last line hints: when you adjust systemd-related config, you often need to reload or restart parts of the systemd setup for changes to apply.

Since the exact commands aren’t spelled out in the source, we’ll stay conceptual:

There are configuration files and unit files for systemd.
If you change those, systemd doesn’t magically know until it’s told to re-read them.

Some practical habits:

Back up before editing.
If you must edit a config or unit file, copy it first with a .bak suffix.
Document your changes.
Keep a simple text log somewhere with: file name, date, and what you changed. Future you will thank present you.
Test reloading on non-critical machines first.
If a reload or restart of systemd config goes sideways, you want to learn that in a safe place.
Validate after changes.
Use the status, is-active, and is-failed commands again to confirm the service still behaves as expected.

This keeps your troubleshooting loop tight and reduces “I changed something and now everything is weird” moments.

Quick Recap and Next Step

On Linux systems that use systemd, systemctl is your main tool for managing services, units, and overall system state. You can:

Confirm systemctl exists before doing anything.
Use status, is-active, is-enabled, and is-failed to quickly understand what’s going on.
List units and unit files to see what’s running and what’s available.
Inspect configuration, properties, and dependencies safely from the command line.
Change system state and configuration carefully, with backups and testing.

Used with respect, systemctl turns dealing with services from guesswork into something structured and predictable.

Need more help? Check the latest CrushEdge posts.

Photo by Brett Jordan on Unsplash