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.
Description of problem:
This is more question like BZ.
I'm maintainer of a daemon (corosync) which needs to run RT priority. With RHEL there is CONFIG_RT_GROUP_SCHED kernel option enabled so it is not possible to call sched_setscheduler (0, SCHED_RR, ... when process is in the cgroup other than root one. The quick workround (working just fine for RHEL 7/8) was to move task to root cpu cgroup. Sadly with cgroup v2 (enabled in RHEL 9) it's no longer possible to move just cpu cgroup (process pid is written to /sys/fs/cgroup/cgroup.procs so all cgroups are moved).
This results in journald unability to match syslog logged entries with corosync.service, so not adding _SYSTEMD_UNIT metadata so "journalctl -u corosync" doesn't show logged messages (one has to use -t which works just fine).
Actually it is even worse, because there are first few messages logged before moving to root cgroup so thanks to journald cache messages logged during first few seconds (5 seconds afaict) have correct metadata, and later messages don't.
Maybe you get some idea how to solve this problem properly so corosync can get RT priotity and syslog messages get _SYSTEMD_UNIT metadata.
I'm opening to systemd for now, but please reassign to other component if you feel there is better match.
Manually moving a process to a different cgroup is unsupported (and has always been). If one does that, one gets to keep the pieces when things break... Anyway, https://lists.freedesktop.org/archives/systemd-devel/2017-July/039210.html suggests how to solve the problem in systemd-compatible way. (Yes, it's still ugly. But it should work.)
Closing, as there is no bug here from systemd's POV.
@dtardon Thank you for suggestion, but are you talking about
ExecStartPost=/bin/cgclassify -g cpu:/ $MAINPID
? Because if it is so, it is doing totally same thing (with cgroup v2) as "manually moving a process" so it has same problem (tested on Fedora Rawhide).
Or are you talking about "echo an RT budget into the relevant cgroup files in the "cpu"
hierarchy"? Because if so, then you have an idea how to do it? Asking because AFAICT there is currently no way how to affect this with cgroup v2 (https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#cpu - WARNING: cgroup2 doesn’t yet support control of realtime processes and the cpu ...)