2018-02-02 18:09:16 UTC
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?