Cgrulesengd is cut in rhel8-based systems

Hello, community!

Recently, I migrate my system from CentOS 7.9 to RockyLinux 8.5.
I managed to set everything up as it was on CentOS, except of libcgroup-tools package.

A file /usr/bin/cgrulesengd In the rhel8-based systems is deprecated and cut. What is a reason to remove cgred from the latest version of the package?

I do not uderstand really, cuz without cgred no way to realtime manipulate user’s processes (restriction rules per user, cgroups v1).

I have installed libcgroup-tools and libcgroup from rhel7 and it’s working fine on Rocky Linux.
But why Red Hat escapes cgred and does not offer an alternative?

Could it relate to V2? World domination with cgroups in RHEL 8: welcome cgroups v2!

1 Like

It does not seem that due to this…
By default RHEL 8 uses cgroups v1 and cgred is a simple programm that moves processes to control groups.

Check rpm -q --changelog libcgroup. Does it contain:

  • Tue Jan 14 2014 … 0.41-1
    • resolves: #966008
      updated to 0.41
    • removed deprecated cgred service
      please use Control Group Interface in Systemd instead
1 Like

@jlehtone he installed libcgroup from RHEL7, so chances are if he checks it, it probably won’t say the same as it would do for us as it would read his installed package.

But yes, I was checking on this last night myself from reading this post, and agree, that cgroups is now managed by systemctl, as per the link you posted and other material I found. This is why cgred no longer exists. Installing packages from RHEL7 on Rocky 8, or even RHEL8, CentOS 8 or any other 8.x derivative is just asking for problems - especially when upgrading packages and ending up in a dependency nightmare because of it. Maybe right now is OK, but later it will most likely cause problems.

As per the original post, the alternative to cgred is systemctl for managing cgroups.

Missed the bit that there is el7 packages in el8 system – an abomination.

The el7 version indeed has different changelog entry:

  • Tue Jan 14 2014 … 0.41-1
    • resolves: #1052471
      updated to 0.41

Looking at version numbers: 0.41-21.el7 and 0.41-19.el8, it is no wonder that dnf can’t raise huge alarm as it should. While both appear “0.41”, they are entirely different beasts, branched ages ago (in 2013, I guess).