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

[Lennart Poettering]

On Mo, 21.02.22 14:14, Felip Moll (lipixx at gmail.com) wrote:

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

Hmm? Hard requirement of what? Not following?

You are leaving processes around when your service dies/restarts?
That's a bad idea typically, and a generally a hack: the unit should
probably be split up differently, i.e. the processes that shall stick
around on restart should probably be in their own unit, i.e. another
service or scope unit.

> 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?

That's not supported. You may only create your own cgroups where you
turned on delegation, otherwise all bets are off. If you but stuff in
/sys/fs/cgroup/user-stuff its as if you placed stuff in systemd's
"-.slice" without telling it so, and things will break sooner or
later, and often in non-obvious ways.

Lennart

--
Lennart Poettering, Berlin