<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
Hello,<div>It appears the situation with set-property is a bit awkward, quoting the man page for systemctl</div><div><div><font color="#24292e"><span style="font-size: 14.4444px">set-property NAME ASSIGNMENT...</span></font></div><div><font color="#24292e"><span style="font-size: 14.4444px">           Set the specified unit properties at runtime where this is supported.</span></font></div><div><font color="#24292e"><span style="font-size: 14.4444px">           This allows changing configuration parameter properties such as</span></font></div><div><font color="#24292e"><span style="font-size: 14.4444px">           resource control settings at runtime. Not all properties may be</span></font></div><div><font color="#24292e"><span style="font-size: 14.4444px">           changed at runtime, but many resource control settings (primarily</span></font></div><div><font color="#24292e"><span style="font-size: 14.4444px">           those in systemd.resource-control(5)) may. The changes are applied</span></font></div><div><font color="#24292e"><span style="font-size: 14.4444px">           instantly, and stored on disk for future boots, unless --runtime is</span></font></div><div><font color="#24292e"><span style="font-size: 14.4444px">           passed, in which case the settings only apply until the next reboot.</span></font></div><div><font color="#24292e"><span style="font-size: 14.4444px">           The syntax of the property assignment follows closely the syntax of</span></font></div><div><font color="#24292e"><span style="font-size: 14.4444px">           assignments in unit files.</span></font></div><div><font color="#24292e"><span style="font-size: 14.4444px"><br /></span></font></div><div><font color="#24292e"><span style="font-size: 14.4444px">           Example: systemctl set-property foobar.service CPUShares=777</span></font></div><div><font color="#24292e"><span style="font-size: 14.4444px"><br /></span></font></div><div><font color="#24292e"><span style="font-size: 14.4444px">           If the specified unit appears to be inactive, the changes will be only</span></font></div><div><font color="#24292e"><span style="font-size: 14.4444px">           stored on disk as described previously hence they will be effective</span></font></div><div><font color="#24292e"><span style="font-size: 14.4444px">           when the unit will be started.</span></font></div></div><div><font color="#24292e"><span style="font-size: 14.4444px"><br /></span></font></div><div><font color="#24292e"><span style="font-size: 14.4444px">but even when --runtime is not passed, and say </span></font><span style="font-size: 12.6px ; color: rgb( 36 , 41 , 46 )">user-1000.slice is active, and s</span><code style="font-size: 12.6px ; font-family: , "consolas" , "liberation mono" , "menlo" , "courier" , monospace ; padding: 0.2em 0.4em ; background-color: rgba( 27 , 31 , 35 , 0.05 ) ; border-radius: 3px ; color: rgb( 36 , 41 , 46 )">ystemctl set-property user-1000.slice MemoryLimit=7G</code><span style="font-size: 12.6px ; color: rgb( 36 , 41 , 46 )"> 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 t</span><span style="color: rgb( 36 , 41 , 46 ) ; font-size: 12.6px">he 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.</span></div><div><span style="color: rgb( 36 , 41 , 46 ) ; font-size: 12.6px"><br /></span></div><div><font color="#24292e"><span style="font-size: 12.6px">It was argued in <a href="https://github.com/systemd/systemd/issues/7106" target="_blank" rel="noopener noreferrer">https://github.com/systemd/systemd/issues/7106</a> 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?</span></font></div>  </body>
</html>