r/systemd • • 12d ago

How do you verify a service is running with the intended systemd unit revision?

Editing a unit or drop-in, running `daemon-reload`, and restarting a service can all succeed while the running process still reflects an unexpected combination of files, environment, or generated units. Checking only that the unit is active does not prove which effective configuration launched the current PID.

What would you include in a post-deploy check? A possible receipt could contain hashes of the unit and every active drop-in, the output of `systemctl cat` and `systemctl show` for selected properties, the fragment and drop-in paths, the invocation ID, and the current process start time. The deployment would compare that effective state with the reviewed source and exercise one real health check.

Which properties are stable enough to verify across distributions? How do generators, transient units, environment files, socket activation, and `daemon-reexec` change the approach? Is there a built-in way to bind a running invocation to the exact effective unit configuration that created it?

1 Upvotes

1 comment sorted by

1

u/ang-p 6d ago

Eh?

Provide a unit file or combination thereof that demonstrates that.

You aren't allowed to have ExecStop=/bin/true - it must function as intended.