On Fr, 02.02.18 19:09, worz (***@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.
Post by worz
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
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 Poettering, Red Hat