[systemd-devel] cgroup messages on service stop

[Michal Koutný]

Hello.

On Wed, Jun 04, 2025 at 10:57:20AM -0600, Orion Poplawski <orion at nwra.com> wrote:
> I'm seeing the following on an EL9.6 system when stopping the bdsec-daemon
> service:
> 
> Jun 03 12:41:12 systemd[427214]: bdsec-daemon.service: Failed to attach
> process to cgroup /system.slice/bdsec-daemon.service/.control because the
> cgroup or one of its parents or siblings is in the threaded mode: Structure
> needs cleaning
> Jun 03 12:41:12 systemd[427214]: bdsec-daemon.service: Failed at step CGROUP
> spawning /opt/bitdefender-security-tools/bin/bdsecd: Structure needs cleaning
> Jun 03 12:41:12 systemd[1]: bdsec-daemon.service: Control process exited,
> code=exited, status=219/CGROUP
> Jun 03 12:41:12 systemd[1]: bdsec-daemon.service: Failed to kill control group
> /system.slice/bdsec-daemon.service, ignoring: Operation not supported
> Jun 03 12:41:33 systemd[1]: bdsec-daemon.service: Failed with result 'exit-code'.
> Jun 03 12:41:33 systemd[1]: bdsec-daemon.service: Consumed 1d 17h 31min 3.836s
> CPU time.
> 
> Can anyone clue me into what this means exactly?

The service has Delegate=yes, i.e. it is free to organize the subtree on
its own. Apparently, the service has created some threaded cgroups
(cgroup.type=threaded) and systemd fails to deal with that. The reason
is that the service isn't _that_ free, see paragraph about threaded
groups in [1], that would need a modification/configuration of the
bdsecd so that it nests threaded cgroups one level deeper :-/

HTH,
Michal

[1] https://systemd.io/CGROUP_DELEGATION/

P.S. I don't think there's strict technical reason for PID1 to avoid
threaded groups so badly but this is how it is implemented currently.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20250630/fffae263/attachment.sig>