On Fr, 02.02.18 19:09, worz (w...@tuta.io) wrote: Humm, your emails are really weirdly formatted. Generally, sending HTML email to technical mailing lists is frowned upon, as replying is very messy. We usually won't complain about this too much, but in this case I have trouble getting good old mutt to make any sense of your formatting, hence, please, next time please send text emails. Thank you for understanding.
> 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? I am not sure I follow, but note that logind generates the per-user slices as transient units, and currently this means that all property changes to it are transient too and won't hit the disk. And yes, this is something we might want to reconsider, i.e. by allowing non-transient property changes stored for transient units. That's why issue #7106 remains open and is marked as RFE... But yeah, we might want to document this too. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
