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
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
