[systemd-devel] set-property does not work properly
worz
worz at tuta.io
Fri Feb 2 18:09:16 UTC 2018
Hello,It appears the situation with set-property is a bit awkward, quoting the man page for systemctlset-property NAME ASSIGNMENT... Set the specified unit properties at runtime where this is supported. This allows changing configuration parameter properties such as resource control settings at runtime. Not all properties may be changed at runtime, but many resource control settings (primarily those in systemd.resource-control(5)) may. The changes are applied instantly, and stored on disk for future boots, unless --runtime is passed, in which case the settings only apply until the next reboot. The syntax of the property assignment follows closely the syntax of assignments in unit files.
Example: systemctl set-property foobar.service CPUShares=777
If the specified unit appears to be inactive, the changes will be only stored on disk as described previously hence they will be effective when the unit will be started.
but even when --runtime is not passed, and say user-1000.slice is active, and systemctl set-property user-1000.slice MemoryLimit=7G should apply it instantly, and store it on disk in /etc for future reboots, at /etc/systemd/system/user-1000.slice.d/50-MemoryLimit.conf. This is not the case, and the contradictory behaviour (wrt the documentation) is that the drop-in is made under /run/systemd/transient/user-1000.slice.d/ even when --runtime was not passed, hence the unit wont stick through reboots.
It was argued in https://github.com/systemd/systemd/issues/7106 that as purely transient objects, drop-ins generated shouldn't reside on disk for this slice, but for the user who does not know if systemctl is a D-Bus client for the Manager, it makes sense for the drop-in to be persistent. Can this be reconsidered, and if this is not possible, atleast a fix be accepted for the documentation to state otherwise?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20180202/48cf70f9/attachment.html>
More information about the systemd-devel
mailing list