Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Created attachment 1585162[details]
reproducer shell script
Description of problem:
When cpuset controller is enabled together with cgroups v2 it will break systemd
in a way that it's not able to move PIDs into scope cgroups. It will not break
only for machined but it will stop working for other tasks, for example if you
ssh into the broken system systemd will fail to start user session.
Version-Release number of selected component (if applicable):
systemd-239-15.el8.x86_64
How reproducible:
100%
Steps to Reproduce:
1. Run the attached reproducer, the first run after clean reboot is successful.
2. Run the attached reproducer again, every other attempt will fail.
Actual results:
For some reason unknown to me (I did not spend too much time figuring it out)
the first attempt will succeed and any other attempt will fail to move process
into the created scope.
Additional info:
Logs from journalctl:
Jun 27 15:05:36 rhel8 systemd-machined[979]: New machine test.
Jun 27 15:05:36 rhel8 systemd[1]: Started Virtual Machine test.
Jun 27 15:05:36 rhel8 kvm[1877]: 1 guest now active
Jun 27 15:05:38 rhel8 kvm[1881]: 0 guests now active
Jun 27 15:05:38 rhel8 systemd-machined[979]: Machine test terminated.
Jun 27 15:05:40 rhel8 systemd-machined[979]: New machine test.
Jun 27 15:05:40 rhel8 systemd[1]: machine-test.scope: Failed to add PIDs to scope's control group: Permission denied
Jun 27 15:05:40 rhel8 systemd[1]: machine-test.scope: Failed with result 'resources'.
Jun 27 15:05:40 rhel8 systemd[1]: Failed to start Virtual Machine test.
Jun 27 15:05:40 rhel8 systemd-machined[979]: Machine test terminated.
Jun 27 15:05:40 rhel8 kvm[1898]: 1 guest now active
Jun 27 15:05:42 rhel8 kvm[1902]: 0 guests now active
Jun 27 15:05:44 rhel8 setroubleshoot[1904]: SELinux is preventing systemd from using the setsched access on a process. For complete SELinux messages run: sealert -l 99e33992-d11e-4c24-a13e-43769e85001e
From /var/log/audit/audit.log:
type=AVC msg=audit(1561640992.773:174): avc: denied { setsched } for pid=1 comm="systemd" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=process permissive=0
Created attachment 1585162 [details] reproducer shell script Description of problem: When cpuset controller is enabled together with cgroups v2 it will break systemd in a way that it's not able to move PIDs into scope cgroups. It will not break only for machined but it will stop working for other tasks, for example if you ssh into the broken system systemd will fail to start user session. Version-Release number of selected component (if applicable): systemd-239-15.el8.x86_64 How reproducible: 100% Steps to Reproduce: 1. Run the attached reproducer, the first run after clean reboot is successful. 2. Run the attached reproducer again, every other attempt will fail. Actual results: For some reason unknown to me (I did not spend too much time figuring it out) the first attempt will succeed and any other attempt will fail to move process into the created scope. Additional info: Logs from journalctl: Jun 27 15:05:36 rhel8 systemd-machined[979]: New machine test. Jun 27 15:05:36 rhel8 systemd[1]: Started Virtual Machine test. Jun 27 15:05:36 rhel8 kvm[1877]: 1 guest now active Jun 27 15:05:38 rhel8 kvm[1881]: 0 guests now active Jun 27 15:05:38 rhel8 systemd-machined[979]: Machine test terminated. Jun 27 15:05:40 rhel8 systemd-machined[979]: New machine test. Jun 27 15:05:40 rhel8 systemd[1]: machine-test.scope: Failed to add PIDs to scope's control group: Permission denied Jun 27 15:05:40 rhel8 systemd[1]: machine-test.scope: Failed with result 'resources'. Jun 27 15:05:40 rhel8 systemd[1]: Failed to start Virtual Machine test. Jun 27 15:05:40 rhel8 systemd-machined[979]: Machine test terminated. Jun 27 15:05:40 rhel8 kvm[1898]: 1 guest now active Jun 27 15:05:42 rhel8 kvm[1902]: 0 guests now active Jun 27 15:05:44 rhel8 setroubleshoot[1904]: SELinux is preventing systemd from using the setsched access on a process. For complete SELinux messages run: sealert -l 99e33992-d11e-4c24-a13e-43769e85001e From /var/log/audit/audit.log: type=AVC msg=audit(1561640992.773:174): avc: denied { setsched } for pid=1 comm="systemd" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=process permissive=0