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

[Felip Moll]

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.

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/5eeeb024/attachment-0001.htm>