systemctl-set-property

Set a property for a running service

$ systemctl set-property [unit] [property]=[value]

$ systemctl set-property [unit] [property_1=value_1 property_2=value_2 ...]

$ systemctl set-property [unit] [property]=[value] --runtime

$ systemctl set-property [unit] [property]=

$ systemctl set-property [unit] [property_1= property_2= ...]

`systemctl set-property UNIT PROPERTY=VALUE [PROPERTY=VALUE...]`

UNIT
    The name of the systemd unit (e.g., `apache.service`, `user@1000.service`) whose properties are to be modified.

PROPERTY=VALUE
    One or more assignments of a property name to its new value. Example: `CPUShares=500`. Multiple property assignments can be provided, separated by spaces.

`systemctl set-property` allows administrators to dynamically adjust the properties of active systemd units, such as services, sockets, or slices, without requiring a restart of the unit or modification of its configuration file. This command is particularly useful for runtime resource management, enabling real-time adjustments to settings like CPU shares (CPUShares), memory limits (MemoryLimit), or I/O weights (IOWeight) for specific services or user sessions.

Changes made using `set-property` are immediate and affect the running instance of the unit. However, it's crucial to understand that these modifications are temporary. They are held in memory and will be lost upon the unit's restart or a system reboot. For permanent changes, the unit's configuration file must be edited, typically using `systemctl edit`. This command empowers fine-grained control over system resources and behavior during operation, aiding in troubleshooting, performance tuning, or adapting to changing workload demands without service interruption.

• Temporary Changes: Modifications are only active for the current runtime and will be lost if the unit is stopped/restarted or the system reboots. They do not alter the unit's configuration file on disk.
• Permissions: Requires root privileges (or appropriate D-Bus permissions) to modify properties of system units. Users can usually modify properties of their own user units.
• Not All Properties Settable: Only certain properties are designed to be changed at runtime. Attempting to set an invalid or non-runtime-settable property will result in an error.
• Immediate Impact: Changes take effect immediately on the running unit, which can have an instant impact on its resource consumption or behavior.
• Validation: Systemd performs some validation, but incorrect values can still lead to unexpected behavior or unit instability.

To persist changes across reboots or unit restarts, you must edit the unit's configuration file. The recommended way is to use `systemctl edit UNIT`, which creates an override file in `/etc/systemd/system/` (or `~/.config/systemd/user/` for user units). After editing, run `systemctl daemon-reload` and then `systemctl restart UNIT` (if applicable).

To identify properties that can be set for a specific unit type, consult the relevant systemd manual pages, such as `man systemd.resource-control(5)` for resource limits, `man systemd.service(5)` for service-specific properties, or `man systemd.slice(5)` for slice properties. Not all properties listed in these manuals are runtime-settable.

The `set-property` subcommand is an integral part of systemd's comprehensive approach to process and service management, introduced as systemd gained prominence as the default init system in Linux distributions. It reflects systemd's capability to manage system state and resources dynamically, leveraging D-Bus for inter-process communication and runtime configuration. While systemd itself emerged around 2010, `set-property` matured alongside features like cgroups integration, allowing for sophisticated, real-time resource governance directly from the command line. Its development underscores the shift towards more flexible and observable system management paradigms in modern Linux environments.

systemctl(1), systemd.unit(5), systemd.resource-control(5), systemd.service(5), systemctl edit(1)