Hello. On Wed, Jun 04, 2025 at 10:57:20AM -0600, Orion Poplawski <or...@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.
signature.asc
Description: PGP signature
