Discussion:
set-property does not work properly
Add Reply
worz
2018-02-02 18:09:16 UTC
Reply
Permalink
Raw Message
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?
Lennart Poettering
2018-02-05 14:06:18 UTC
Reply
Permalink
Raw Message
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
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
Loading...