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?
systemd-devel mailing list

Reply via email to