Transient and User Services

Scope: two ways to run services without hand-writing unit files in /etc — one-shot transient units from the command line, and per-user services that need no root.

systemd-run: a service for one command

systemd-run wraps any command in a transient unit — created on the fly, supervised like a real service, gone when it finishes:

sudo systemd-run --unit=mere-transient \
    /bin/bash -c 'echo hello-from-a-transient-unit'

Running as unit: mere-transient.service; invocation ID: baf992c9...

and its output went where service output goes:

journalctl -u mere-transient.service

Oct 16 18:32:56 htch bash[16567]: hello-from-a-transient-unit
Oct 16 18:32:56 htch systemd[1]: mere-transient.service: Deactivated successfully.

Why bother for a shell one-liner: the command gets the journal (no orphaned nohup.out), the process-group cleanup (children die with it), and any unit property — --property=Restart=on-failure, CPU/memory limits, sandboxing flags — via flags. "Run this like a service, just for now" is a real and frequent need; this is its native form. Add --scope instead and the command runs attached to your terminal inside a lightweight unit — the way to put an interactive process in its own cgroup without ceremony. The interactive shell form is (documented).

User services: no root, your own systemd

(Documented — this guide's test environment had no per-user manager session to run these against; the mechanism below is the standard one.)

Every logged-in user gets a private systemd instance, managed with the same commands plus --user:

systemctl --user start myapp.service
systemctl --user enable myapp.service
journalctl --user -u myapp.service

Units live in ~/.config/systemd/user/ and mirror the system format exactly — WantedBy=default.target is the user-land equivalent of multi-user.target. Use them for personal daemons: sync jobs, dev servers, your own bots — things that are yours, shouldn't need sudo to manage, and shouldn't run as root anyway.

The one wrinkle is lifetime: a user manager traditionally starts at login and stops at logout. Lingering breaks that link:

sudo loginctl enable-linger <username>

With lingering on, your user manager starts at boot and survives logout — user services become real always-on services. That's how mortals run personal long-lived things on a server without touching /etc/systemd/system at all.

Rule of thumb between the two worlds: if other users or the system itself depends on it, it's a system service. If it's yours alone, it's a user service, possibly with linger.