CachyOS / CachyOS/copr-linux-cachyos

ananicy-cpp on Fedora 44: cgroup v2 CPU controller not enabled for CPUQuota groups

Open
#93 3 comments 0 reactions 0 assignees View on GitHub
Dominant language
Shell
Stars
349
Forks
34
Avg merge
21h 59m
Merged PRs (30d)
2

Description

# ananicy-cpp on Fedora 44: cgroup v2 CPU controller not enabled for CPUQuota groups

## Summary

On Fedora 44 with `ananicy-cpp` and `cachyos-ananicy-rules`, the service starts and loads the rules, but logs a warning saying that cgroups are not available or not enabled.

The system itself has cgroup v2 enabled and exposes the `cpu` controller correctly. Manually enabling `+cpu` for the ananicy cgroup path before starting the service makes the warning disappear and allows ananicy to create its CPUQuota cgroups.

This looks like a service/package initialization issue rather than a kernel issue.

## Environment

```text
Distribution: Fedora 44 Workstation
Kernel: 7.0.3-cachyos1.fc44.x86_64
CPU: AMD Ryzen AI 9 HX 370
Package: ananicy-cpp-1.1.1-9.fc42.x86_64
Package: cachyos-ananicy-rules-1.1.36-1.fc44.x86_64
Service: ananicy-cpp.service
```

## ananicy-cpp status

The service is enabled and running:

```text
ananicy-cpp.service
Loaded: enabled
Active: active (running)
```

At startup it loads the rules:

```text
Config cgroup_load: true
Config apply_cgroup: true
Config rule_load: true
Config type_load: true
Worker initialized with 9149 rules
```

The installed CachyOS rules include CPUQuota cgroups:

```text
/etc/ananicy.d/00-cgroups.cgroups
```

```json
{ "cgroup": "cpu90", "CPUQuota": 90 }
{ "cgroup": "cpu85", "CPUQuota": 85 }
{ "cgroup": "cpu80", "CPUQuota": 80 }
```

## Problem

On a normal service start, ananicy logs:

```text
cgroup2 at /sys/fs/cgroup/ananicy_test_cgroup2 doesn't have a cpu controller available, skipping
Cgroups are not available on this platform (or are not enabled)
Cgroups are not available on this platform (or are not enabled)
Cgroups are not available on this platform (or are not enabled)
```

However, the system does have cgroup v2 and the `cpu` controller available:

```bash
findmnt -T /sys/fs/cgroup -o TARGET,FSTYPE,OPTIONS
cat /sys/fs/cgroup/cgroup.controllers
cat /sys/fs/cgroup/cgroup.subtree_control
```

Result:

```text
TARGET FSTYPE
/sys/fs/cgroup cgroup2

cgroup.controllers:
cpuset cpu io memory hugetlb pids rdma misc dmem

cgroup.subtree_control:
cpu io memory pids
```

## Manual workaround

This workaround fixes the warning:

```bash
sudo sh -c 'echo +cpu > /sys/fs/cgroup/ananicy_test_cgroup2/cgroup.subtree_control'
sudo systemctl restart ananicy-cpp
```

After that, the service starts without the original cgroup availability warning:

```text
Creating Cgroups...
Finished creating Cgroups...
Worker initialized with 9149 rules
```

The CPUQuota cgroups are then present and have `cpu.max` configured:

```text
/sys/fs/cgroup/cpu80/cpu.max -> 1920000 100000
/sys/fs/cgroup/cpu85/cpu.max -> 2040000 100000
/sys/fs/cgroup/cpu90/cpu.max -> 2160000 100000
```

This system has 24 logical CPUs, so these values match 80%, 85%, and 90% of total CPU capacity.

## Local persistent workaround

I used this systemd drop-in locally:

```ini
# /etc/systemd/system/ananicy-cpp.service.d/10-enable-cgroup-cpu.conf

[Service]
ExecStartPre=/usr/bin/mkdir -p /sys/fs/cgroup/ananicy_test_cgroup2
ExecStartPre=/usr/bin/sh -c 'grep -qw cpu /sys/fs/cgroup/ananicy_test_cgroup2/cgroup.subtree_control || echo +cpu > /sys/fs/cgroup/ananicy_test_cgroup2/cgroup.subtree_control'
```

Then:

```bash
sudo systemctl daemon-reload
sudo systemctl restart ananicy-cpp
```

## Question

Would it make sense for the Fedora packaging/service unit to ensure that the required cgroup v2 CPU controller is enabled before `ananicy-cpp` tries to create or validate its CPUQuota cgroups?

Alternatively, if the current service assumes systemd should prepare this differently, is there a recommended unit-level fix for Fedora 44/cgroup v2?

Contributor guide

Open the contributing guide

Research direction

Start by inspecting ananicy-cpp.service and the /etc/ananicy.d/00-cgroups.cgroups rules, then reproduce the startup warning with the cgroup v2 controller files under /sys/fs/cgroup/ananicy_test_cgroup2. Compare normal startup with the documented systemd drop-in workaround; done means CPUQuota groups are created with cpu.max and the cgroup availability warnings no longer appear.

Written by the indexing model from the issue text.

Assessment

Tech stack
fedora, linux, shell
Domain
devops, operating-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.