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 - lip...@gmail.com Tlf. - +34 659 69 40 47
