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
├── 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.
