systemd-run

Start a transient service

$ sudo systemd-run [command] [argument1 argument2 ...]

$ systemd-run --user [command] [argument1 argument2 ...]

$ sudo systemd-run [[-u|--unit]] [name] --description [string] [command] [argument1 argument2 ...]

$ sudo systemd-run [[-r|--remain-after-exit]] --set-env=[name]=[value] [command] [argument1 argument2 ...]

$ sudo systemd-run --on-calendar=[calendar_event] [command] [argument1 argument2 ...]

$ systemd-run [[-r|--remain-after-exit]] --pty [command]

$ systemd-run [[-p|--property]] MemoryMax=[memory_in_bytes] [[-p|--property]] CPUQuota=[percentage_of_CPU_time]% --wait [command]

$ [command1] | systemd-run [[-P|--pipe]] [command2] | [command3]

systemd-run [OPTIONS...] {COMMAND} [ARGUMENTS...]

--unit=UNIT
    Specify the name for the transient unit. If omitted, systemd-run generates one automatically.

--scope
    Run the command as a scope unit instead of a service unit. Scopes typically manage externally started processes, while services manage processes started by systemd itself.

--slice=SLICE
    Assign the transient unit to a specific slice. This is used for hierarchical resource management.

--property=NAME=VALUE
    Set a specific unit property for the transient unit. For example, use 'MemoryLimit=500M' to limit memory usage.

--wait
    Wait for the command or unit to terminate before exiting systemd-run itself. The exit code will be that of the executed command.

--user
    Run the command as a user service under the invoking user's systemd instance, instead of the system-wide instance.

--uid=UID, --gid=GID
    Set the user and/or group ID that the executed command will run as.

--setenv=VAR=VALUE
    Set an environment variable for the executed command.

--working-directory=PATH
    Set the working directory for the executed command.

systemd-run is a versatile command-line utility used to execute commands or scripts as temporary, "transient" systemd service or scope units. This powerful feature allows processes to benefit from systemd's robust management capabilities, including resource control (CPU, memory, I/O), security sandboxing, logging, and dependency management, without the need to create persistent .service unit files.

It's particularly useful for running one-off tasks, testing service configurations, creating temporary background daemons with specific resource limits, or isolating processes for security and stability. By leveraging systemd's cgroup capabilities, systemd-run provides a controlled execution environment, making it an essential tool for system administrators and developers alike.

Transient units created by systemd-run are, by definition, not persistent across reboots. For permanent services, a dedicated .service unit file is required. The complexity of systemd-run increases with the number of properties specified, requiring familiarity with systemd unit configuration directives. Running commands with elevated privileges still requires appropriate permissions.

Unless the --remain-after-exit option is used, transient units created by systemd-run are automatically cleaned up and removed from systemd's configuration after the executed command exits or the unit is stopped. This makes them ideal for one-off tasks that don't require persistent state.

The standard output (stdout) and standard error (stderr) of commands run via systemd-run are automatically captured by the systemd journal. This allows for centralized logging and easy retrieval of command output using journalctl -u <unit_name>, even for short-lived processes.

One of the most powerful aspects of systemd-run is its ability to apply sophisticated resource limits (e.g., CPU, memory, I/O bandwidth, number of processes) to the executed command using the --property= option. This allows for fine-grained control over how processes consume system resources without modifying system-wide configurations.

systemd-run was introduced as an integral part of the systemd initialization system, which began widespread adoption in Linux distributions around 2010. Its development aimed to provide a flexible command-line interface for interacting with systemd's advanced process and resource management capabilities, allowing administrators to dynamically create and manage units without the overhead of writing static configuration files. It has evolved alongside systemd, incorporating new features like cgroup v2 support.

systemctl(1), journalctl(1), systemd.service(5), systemd.scope(5), systemd.slice(5), systemd.resource-control(5)