Run transient work

systemd-run creates a transient unit without leaving a permanent unit file behind. You get the machinery of a service — journal capture, resource limits, cgroup tracking — for a command you will run once.

Start with a harmless one:

systemd-run --user --wait /usr/bin/true

Running as unit: run-r1f3a2b9c4d.service; invocation ID: 7b0f...
Finished with result: success
Main processes terminated with: code=exited, status=0/SUCCESS
Service runtime: 4ms

--wait makes the command block until the unit finishes and print the result. --user runs it in your user manager, no root needed.

Where this earns its keep

A transient service is useful for an administrative command that needs resource controls or journal capture. Say you need to rebuild a search index, it eats memory, and you refuse to let it take down the API on the same box:

sudo systemd-run --unit=reindex -p MemoryMax=1G -p CPUQuota=50% \
  /usr/local/bin/reindex-search

The job now has a name, a memory ceiling, and its output lands in the journal:

systemctl status reindex.service
journalctl -u reindex.service -f

Compare that with running it from your shell: no limits, output lost when your SSH session drops, and the process dies with the session unless you remembered nohup or tmux.

A transient scope is the other variant: systemd-run --scope places an existing command tree under systemd management while it still runs attached to your terminal. Useful when you want limits on an interactive process.

The cleanup gotcha

Successful transient units vanish when they finish. Failed ones stay visible in systemctl --failed until you clear them with systemctl reset-failed reindex.service. That is a feature — the failure evidence survives — but it surprises people who expect transient to mean traceless.

Run the --user --wait example above, then inspect what remains with systemctl --user status. Then decide the boundary for yourself: anything you run twice, or that a teammate must find and understand later, deserves a permanent unit file instead.