Alright, let’s get our hands dirty with the actual commands you’ll use to boss systemd around. Forget the abstract architecture for a moment; this is the control panel. The systemctl command is your multi-tool, and these six subcommands—start, stop, restart, enable, disable, status—are the Phillips head, flat head, and that weird star-shaped bit you’ll use 90% of the time.

Think of a unit file as a recipe. systemctl start is you, in the kitchen, following that recipe right now to make a single dish. systemctl enable is you programming your fancy bread machine to automatically make that loaf every morning at 7 a.m. They are fundamentally different operations. Confusing them is the number one rookie mistake, and it leads to that classic head-scratcher: “I started it, but after a reboot it was gone!” Well, yeah. You made a sandwich; you didn’t set up a sandwich subscription service.

Starting, Stopping, and the Theater of Restarting

Starting and stopping are as straightforward as they come. You point systemctl at a unit and tell it to get going or knock it off.

sudo systemctl start nginx.service
sudo systemctl stop nginx.service

Notice the sudo? That’s because you’re mucking with the core system, and systemd rightly doesn’t trust just any user to do that. Now, restart is where we get our first taste of systemd’… let’s call it “opinionated” logic. systemctl restart does exactly what you think: it stops the unit and then starts it again. It does not care if the unit was already running. This is a blunt instrument.

But wait, there’s another option: reload. This one’s nifty. It tells the service (assuming it’s written to listen for this signal) to reload its configuration files without tearing down the main process. This is great for applying new settings without dropping active connections. The problem? Not all services support it.

Enter systemctl reload-or-restart. This is the smarter, more polite option. It says, “Hey, service, can you please just reload your config? No? Okay, fine, we’ll do it the hard way.” You should almost always use this instead of a blunt restart.

# The polite way (try reload, fall back to restart)
sudo systemctl reload-or-restart nginx.service

# The barbarian way (stop, then start, no questions asked)
sudo systemctl restart nginx.service

Enabling and Disabling: The Boot-Time Ballet

This is about the next boot, not the current one. Enabling a unit doesn’t start it; it just creates a symlink from the multi-user target’s .wants directory to your unit file. (Yes, it’s just symlinks. I told you it was simple underneath all the jargon). This symlink is systemd’s to-do list for boot time. Disabling removes that symlink, taking the unit off the boot-time checklist.

# Add nginx to the boot-time checklist
sudo systemctl enable nginx.service

# Remove nginx from the boot-time checklist
sudo systemctl disable nginx.service

Here’s a classic pitfall: you disable a service but it’s still running. Of course it is! Disabling only affects the next boot. If you want to stop it now and prevent it from starting on next boot, you need a one-two punch:

sudo systemctl stop nginx.service
sudo systemctl disable nginx.service

status: Your First and Best Diagnostic Tool

Forget ps aux | grep nginx. systemctl status is your new best friend. It gives you a concentrated shot of information: whether the unit is active, its most recent log entries (via journalctl), the process ID, and, crucially, the exact command it used to execute.

systemctl status nginx.service

The output will scream at you in red if it failed, and it will show you the last few log lines. If something is wrong, this is literally the first place you look. It often tells you exactly what the problem is, saving you minutes of pointless digging. It’s so useful I often find myself aliasing ss to systemctl status because I type it that often.

The “But It Didn’t Work!” Checklist

So you ran start and it failed. Now what?

  1. Run status. I’m not kidding. Read the output. The error is usually right there.
  2. Did you use the full unit name? systemctl start nginx often works, but systemctl start nginx.service is explicit. Ambiguity is the enemy.
  3. Check the logs. status shows a preview, but for the full picture, run sudo journalctl -u nginx.service -xe. The -xe flags give you paged output and jump to the end, which is where the most recent and relevant errors live.
  4. Remember the daemon-reload. If you just edited a unit file, systemd needs to be told to look at its new instructions. A sudo systemctl daemon-reload is often the missing piece of the puzzle before a start will work. Forgetting this is the number two rookie mistake.