A Safe systemctl Workflow for Starting and Checking Services

You ran systemctl start, it printed nothing, and after the next reboot the service is gone. In about 15 minutes you will inspect, start, enable and reload a systemd service without mixing up which command does what.

The route

Jump straight to the step you need, or tick off Done means at the end.

1. Confirm the unit name and current state
2. Read status for people, properties for scripts
3. Start a stopped service, then verify it
4. Reload the right thing
5. Separate boot enablement from starting now
6. Understand preset policy before applying it
7. Use failures as a checkpoint

The examples use systemd 255.4 from the Ubuntu package systemd 255.4-1ubuntu8.17.

What you need: a shell and the name of an installed service.
Reading is free. Status checks normally work as an ordinary user.
Changing needs sudo. Starting, stopping, enabling and editing system unit files usually do.
Read-only checks use cron.service. State-changing examples are marked clearly.

1. Confirm the unit name and current state

List the installed unit files rather than guessing a service name:

$ systemctl list-unit-files --type=service --state=enabled | head
UNIT FILE                          STATE   PRESET
apparmor.service                   enabled enabled
apport.service                     enabled enabled
blk-availability.service           enabled enabled
console-setup.service              enabled enabled
cron.service                       enabled enabled

Your list will differ. This shows unit files installed on the machine and their enablement state.

Tip

list-unit-files is not list-units. The latter shows units currently loaded into systemd's memory and, by default, only active, failed or job-pending ones.

Pick a real unit from your own output. cron.service is installed here:

$ systemctl is-active cron.service
active
$ systemctl is-enabled cron.service
enabled

is-active asks whether the unit is running now.
is-enabled asks whether its unit file is hooked into the boot or activation dependency graph.
They are separate facts. A service can be enabled but stopped, or active without being enabled for boot.

Checkpoint

In scripts, test the exit status rather than parsing the word. Both checks return 0 when the condition is true; add --quiet to suppress output.

2. Read status for people, properties for scripts

Use status when a human is diagnosing a problem:

$ systemctl status cron.service
● cron.service - Regular background program processing daemon
     Loaded: loaded (...; enabled; preset: enabled)
     Active: active (running) ...

Timestamps, process ID and journal lines are host-specific. By default, status shows only a little recent log output and shortens lines to fit the terminal. Add --full or --lines=50 when truncation hides the useful part. Status is for humans, not stable parsing.

For a script, ask for named properties:

$ systemctl show cron.service \
    --property=ActiveState --property=SubState --property=UnitFileState
ActiveState=active
SubState=running
UnitFileState=enabled

Tip

systemctl cat cron.service shows the unit's source file and drop-ins as they are on disk. If a unit file has changed, systemd may still be running the old in-memory version until you run daemon-reload.

3. Start a stopped service, then verify it

Starting activates a service now. It does not make it start on the next boot.

$ sudo systemctl start SERVICE.service
$ systemctl is-active SERVICE.service
active

Replace SERVICE.service with an exact unit name. A successful start prints no success message, so the follow-up check is what tells you it worked.

Recovery

If the start fails, read systemctl status SERVICE.service, then the unit's journal with journalctl --unit=SERVICE.service.

To stop it again:

$ sudo systemctl stop SERVICE.service
$ systemctl is-active SERVICE.service
inactive

Warning

Stopping a service can interrupt users, scheduled work or dependent units, so check its status and dependencies first on a production host. A stop does not undo enablement: an enabled service may start again at boot or when another unit triggers it.

4. Reload the right thing

Two similar names, two different targets:

systemctl reload SERVICE.service asks the service to reread its own application configuration. It does not reread the systemd unit file.
sudo systemctl daemon-reload makes systemd reread unit files and drop-ins after you change them. It does not restart the service.

After a unit-file edit, refresh the service like this:

$ sudo systemctl daemon-reload
$ sudo systemctl reload-or-restart SERVICE.service
$ systemctl status SERVICE.service

reload-or-restart reloads the service if it supports reload; otherwise it stops and starts it. If the service is not running, it starts it.

Warning

That restart fallback can cause an outage. When a restart is unacceptable and the service documents reload support, use plain reload.

Tip

Do not run daemon-reload after every application config change. Use it when the unit definition or a drop-in changed; use reload when the application configuration changed.

5. Separate boot enablement from starting now

Enabling creates the symlinks described in the unit's [Install] section. It does not start anything:

$ sudo systemctl enable SERVICE.service
$ systemctl is-enabled SERVICE.service
enabled
$ systemctl is-active SERVICE.service
inactive

Want both? enable --now enables and starts in one command:

$ sudo systemctl enable --now SERVICE.service
Created symlink ...
$ systemctl is-enabled SERVICE.service
enabled
$ systemctl is-active SERVICE.service
active

Undo with sudo systemctl disable SERVICE.service. It removes all symlinks to the matching unit files, including ones created by hand, but does not stop the running service.
disable --now also stops it. Use it only when you mean that.
Use the real unit name. Do not enable an alias when the operation needs the real name; check with systemctl list-unit-files.
Static units cannot be enabled in the usual way: they have no install instructions.

6. Understand preset policy before applying it

systemctl preset SERVICE.service resets the unit's enablement to the first matching rule in the preset files. Presets are policy, not another spelling of enable. On this system the search paths are:

/etc/systemd/system-preset/
/run/systemd/system-preset/
/usr/lib/systemd/system-preset/

A preset file holds one directive and unit name per line:

# /etc/systemd/system-preset/20-local-services.preset
enable SERVICE.service
disable another-service.service
ignore third-service.service

First match wins.
enable and disable change the enablement state; ignore leaves existing configuration alone.
Files sort lexicographically, and an administrator file under /etc overrides a vendor file with the same name.
Presets never start or stop a running service.

Warning

Applying a preset changes persistent enablement. Inspect the policy, and record the old state if you need exact rollback, before you run it:

$ systemctl preset SERVICE.service
$ systemctl is-enabled SERVICE.service
enabled

Recovery

Restore the previous state with the matching explicit command, such as sudo systemctl enable SERVICE.service or sudo systemctl disable SERVICE.service.

7. Use failures as a checkpoint

When a service is not active, capture three separate facts before changing anything:

$ systemctl status SERVICE.service --no-pager
$ systemctl show SERVICE.service --property=LoadState --property=ActiveState --property=SubState
$ journalctl --unit=SERVICE.service --no-pager -n 50

inactive means the service is not running.
failed means systemd recorded a failure, often a non-zero exit, abnormal termination or timeout.
Neither explains the cause. Read the status and journal, fix the underlying configuration, then retry with sudo systemctl restart SERVICE.service.

Tip

sudo systemctl reset-failed SERVICE.service clears the recorded failed state and its start-rate counters. Use it only when you mean to; it does not repair the service.

Done means

Unit name confirmed with list-unit-files.
State checked with is-active, enablement with is-enabled.
status for people, show for scripts.
Reloads kept straight: service reload versus systemd daemon-reload.
You know what your change does: start, stop, enable, or merely inspect.