[systemd-devel] unable to attach pid to service delegated directory in unified mode after restart

[Barry]

> On 21 Feb 2022, at 21:16, Felip Moll <lipixx at gmail.com> wrote:
> 
> 
> 
>> You could invoke a man:systemd-run for each new process. Than you can
>> put every single job in a seperate .slice with its own
>> man:systemd.resource-control applied.
>> This would also mean that you don't need to compile against libsystemd.
>> Just exec() accordingly if a systemd-system is detected.
>> 
>> BR
>> Silvio
> 
> Silvio,
> 
> As I commented in my previous post, creating every single job in a separate slice is an overhead I cannot assume.
> An HTC system could run thousands of jobs per second, and doing extra fork+execs plus waiting for systemd to fill up its internal structures and manage it all is a no-no.

Are you assuming this or did you measure the cost?

Barry

> 
> One other option that I am thinking about is extending the parameters of a unit file, for example adding a DelegateCgroupLeaf=yes option.
> 
> DelegateCgroupLeaf=<yes|no>. If set to yes an extra directory will be created into the unit cgroup to place the newly spawned service process. This is useful for services which need to be restarted while its forked pids remain in the cgroup and the service cgroup is not a leaf anymore. This option is only valid when using Delegate=yes and under a system in unified mode.
> 
> E.g. in my example, that would end up like this:
> /sys/fs/cgroup/system.slices/sgamba1.service   <------ This is Delegated=yes DelegateMultiCgroups=yes
> ├── sgamba1   <------ The spawned process would be always put in here by systemd.
> ├── user1_stuff
> ├── user2_stuff
> └── user3_stuff
> 
> I think this idea could work for cases like the one exposed here, and I see this would be quite useful.
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220221/c008e0f8/attachment.htm>