[systemd-devel] set-property does not work properly

[Lennart Poettering]

On Fr, 02.02.18 19:09, worz (worz at 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