Description of problem:

A customer reports that his service enabling Delegation (a podman container actually) cannot start properly because it has some ExecStartPost command.
This happens with cgroup unified hierarchy only.
Thanks to his reproducer (see below), I can confirm there is an issue due to having systemd start the ExecStartPost command to root's node, which is not possible and returns EBUSY.

It seems like we need to backport https://github.com/systemd/systemd/pull/10813/files which is related to issue https://github.com/systemd/systemd/issues/10482.

What is weird is that my own reproducer, not using podman but with just delegation and some child hierarchy, doesn't fail for me, so somehow podman must "protect" the hierarchy.

Version-Release number of selected component (if applicable):

systemd-239 up to systemd-239-74.el8_8 included

How reproducible:

Always

Steps to Reproduce:
1. Boot the system with "systemd.unified_cgroup_hierarchy=1"
2. Create a container service unit

  # cat /etc/containers/systemd/delegate_issue.container 
  [Unit]
  Description=The sleep container
  After=local-fs.target
  
  [Service]
  TimeoutStopSec=2
  
  [Container]
  Image=ubi8
  Exec=sleep 1000

3. Reload systemd so that service generation is performed and start then stop the service

  # yum -y install crun
  # systemctl daemon-reload
  # systemctl start delegate_issue.service
  # systemctl stop delegate_issue.service
  # systemctl status delegate_issue.service

Actual results:

● delegate_issue.service - The sleep container
   Loaded: loaded (/etc/containers/systemd/delegate_issue.container; generated)
   Active: failed (Result: timeout) since Mon 2023-06-19 12:53:58 CEST; 2s ago
  Process: 2243 ExecStopPost=/usr/bin/rm -f /run/delegate_issue.cid (code=exited, status=219/CGROUP)
  Process: 2242 ExecStopPost=/usr/bin/podman rm -f -i --cidfile=/run/delegate_issue.cid (code=exited, status=219/CGROUP)
  [...]

Expected results:

Execution of ExecStopPost commands and no failure with 219/CGROUP status

Additional info:

Stracing systemd shows EBUSY on PID 2242, then child of 2242 (2243) fails as well:

# grep -A2 "write(.*/sys/fs/cgroup/system.slice/delegate_issue.service/" /tmp/systemd.strace
[...]
1     12:53:58.754846 write(72</sys/fs/cgroup/system.slice/delegate_issue.service/cgroup.procs>, "2242\n", 5) = -1 EBUSY (Device or resource busy) <0.000006>
2243  12:53:58.764451 write(3</sys/fs/cgroup/system.slice/delegate_issue.service/cgroup.procs>, "2243\n", 5 <unfinished ...>
2243  12:53:58.764467 <... write resumed>) = -1 EBUSY (Device or resource busy) <0.000010>