Wait explicitly when a systemd-run caller needs task completion

A successful transient-service launch can return before the underlying work has finished.

Source facts

The Debian systemd-run manual describes transient service execution as asynchronous by default: the command returns after execution begins. The --wait option changes the service-oriented workflow to wait for completion. A transient scope instead runs with the caller as parent and has synchronous behavior. Service and scope modes also differ in execution-environment inheritance.

Source: Debian systemd manual — systemd-run(1) — systemd — Debian trixie — Debian Manpages.

Applicability

Review systemd-run service/scope lifecycle and waiting behavior in the Debian trixie manual.

DSE recommendation

DSE recommends deciding whether automation needs launch acknowledgement or a final task result. Choose service or scope from the intended lifecycle and environment, then select supported waiting behavior explicitly. Keep the generated unit name with the job record so later status and logs can be retrieved. Do not mark a backup, report, or migration complete merely because the transient unit was accepted. Review exit-status handling in wrappers and account for long-running tasks that should not block an interactive administration session indefinitely.

Verification

In a nonproduction invocation, run a harmless delayed command and observe when the caller returns under the intended options. Compare the final unit result with the wrapper’s reported status. Verify logs and cleanup remain accessible for the required review period after the task ends. Retain the generated unit identity, wrapper return time and final task status together. Have the automation owner demonstrate the failed-command case so a launch acknowledgement cannot silently become the job’s completion signal.

Official reference

Debian systemd manual — systemd-run(1) — systemd — Debian trixie — Debian Manpages. Reviewed October 20, 2026.