systemd Drop-Ins: Check the File, the Loaded Unit, and the Running Process

Suppose you point a queue worker at a new configuration file using a systemd drop-in. You can see the edit on disk, but the worker still reads the old configuration. Before editing another file, ask which of three things is stale: the files systemd can find, the unit it has loaded, or the process already running.

Use systemctl cat to inspect the backing files, systemctl show to check the manager’s loaded settings, and the worker’s runtime evidence to check what took effect. If the file changed but the loaded command didn’t, check whether systemd needs a daemon reload. If the manager has the new command and the old worker is still running, plan a service restart when it is safe to interrupt the work.

Compare the file with what the manager knows

unit=report-worker.service
systemctl cat "$unit"
systemctl show "$unit" \
  -p FragmentPath -p DropInPaths -p NeedDaemonReload \
  -p ExecStart -p MainPID -p ActiveState

Substitute the real system service name. If you manage a user service, run the equivalent commands with systemctl --user as the owning user and use that same manager for later actions. The systemctl manual notes that cat displays files on disk, which can differ from what the manager has loaded. Treat command arguments as potentially sensitive when sharing output.

If the drop-in you edited is missing, check the actual unit name, scope and file path. If there are several drop-ins, inspect them together. The systemd unit manual explains how same-named files are resolved by directory precedence and how differently named files are applied in filename order. A local override can still be followed by a differently named drop-in. Check the actual list before assuming one file wins.

Replace the old start command explicitly

For this example, the unit has one ExecStart and the goal is to replace it. In the drop-in, first clear the existing command list, then add the new command. Don’t copy this over a service that deliberately runs several start commands without reviewing those steps. The systemd service manual documents the empty assignment and the special rules for Type=oneshot.

[Service]
ExecStart=
ExecStart=/opt/report-worker/bin/worker --config /etc/report-worker/staging.toml

Reload the unit definition, then verify the process

After a reviewed edit, use systemctl daemon-reload in the correct manager and repeat systemctl show. This reloads unit definitions. It does not launch the existing worker again. If the loaded ExecStart is now correct, drain or pause work as appropriate and restart the service in an approved window. A service-level reload asks the application to reload its own configuration where supported. It doesn’t replace the start command of the running process.

After restart, check service status and recent logs, then run one representative job. Verify a safe marker that distinguishes the expected configuration, such as a staging queue name recorded by the app. A PID can help you inspect the worker, but it can be zero for an inactive service, can change for other reasons, and may represent a supervisor. The workload result is the final check.

Try the sequence on a disposable worker first. Record the loaded command before and after the daemon reload, then record which configuration the worker uses after the restart. For a real service on a Cube, the Krova runner setup guide shows one workload that can be installed as a systemd service.

This guide was prepared with AI assistance using the linked manuals. The worker and paths are hypothetical. No production service was changed.