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

[Felip Moll]

Hello,

I am creating a software which consists of one daemon which forks several
processes from user requests.
This is basically acting like a job scheduler.

The daemon is started using a unit file and with Delegate=yes option,
because every process must be constrained differently. I manage my cgroup
hierarchy, create some leaves into the tree and put each pid there.
For example, after starting up the service and receiving 3 user requests, a
tree under /sys/fs/cgroup/system.slice/ could look like:

sgamba1.service/
├── daemon_pid
├── user1_stuff
├── user2_stuff
└── user3_stuff

I create the hierarchy and set cgroup.subtree_control in the root directory
(sgamba1.service in the example) and everything runs smoothly, until when I
decide to restart my service.

The service then cannot restart:

feb 18 19:48:52 llit systemd[1143296]: sgamba1.service: Failed to attach to
cgroup /system.slice/sgamba1.service: Device or resource busy
feb 18 19:48:52 llit systemd[1143296]: sgamba1.service: Failed at step
CGROUP spawning /path_to_bin/mydaemond: Device or resource busy

This is because systemd tries to put the pid of the new daemon in
sgamba1.service/cgroup.procs and this would break the "no internal process
constrain" rule for cgroup v2, since sgamba1.service is not a leaf anymore
because it has subtree_control enabled for the user stuff.

One hard requirement is that user stuff must live even if the service is
restarted.

What's the way to achieve that? I see one easy way, which is to move user
stuff into its own cgroup and out of sgamba1.service/, but then it will run
outside a Delegate=yes unit. What can happen then?
Will systemd eventually migrate my processes?
How do services workaround that issue?
If I am moving user stuff into the root /sys/fs/cgroup/user_stuff/, will
systemd touch my directories?

Thank you.


*--Felip Moll*
E-Mail - lipixx at gmail.com
Tlf. - +34 659 69 40 47
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220221/e56ba98e/attachment.htm>