Clear systemd path-trigger conditions after processing

A still-satisfied path condition can immediately start the service again.

Source facts

The Debian systemd.path manual states that monitored paths are checked again when a triggered service terminates, including after failure. A remaining condition can restart the service immediately. Service start-rate limits protect against busy loops, and hitting that limit also fails the path unit. PathChanged and PathModified additionally differ in which writes trigger activation.

Source: Debian systemd manual — systemd.path(5) — systemd — Debian trixie — Debian Manpages.

Applicability

Review systemd path-trigger conditions and start-rate failure using the Debian trixie systemd.path manual.

DSE recommendation

DSE recommends defining how the worker consumes, renames, or otherwise clears the triggering condition. Keep unfinished input distinguishable from successfully processed input and ensure retries do not repeat harmful side effects. Decide which file event is intended rather than choosing a directive by its name alone. Monitor the path unit as well as its service because a rate-limit failure can stop future activation. Include a controlled recovery procedure that fixes the underlying condition before resetting failed state.

Verification

Using disposable input, observe a successful processing cycle and a deliberately persistent trigger. Confirm the worker does not loop uncontrollably and that rate-limit failure is visible. Exercise interrupted processing and verify the next activation can safely identify unfinished work without losing or duplicating the logical task. Retain the input-state transitions and both unit states with the exercise. Ask the worker owner to demonstrate the approved recovery from a failed path unit after the original persistent condition has been corrected.

Official reference

Debian systemd manual — systemd.path(5) — systemd — Debian trixie — Debian Manpages. Reviewed October 20, 2026.