After uncertain amount of time cpufreqctl keeps spawning infinite processes

[BloodyIron]

So recently I've noticed that "journalctl --dmesg --boot --since=yesterday" keeps using some of my CPU after a day or so since previous reboot/power cycle.

I used sysdig "sudo sysdig evt.type=execve and evt.arg.exe=journalctl" to dig down into what's triggering this execution.

After digging further, I see (with sysdig looking at bash)...

2229639 07:58:36.804953862 3 bash (2010162.2010162) < execve res=0 exe=bash args=/usr/bin/cpufreqctl.--throttle-events. tid=2010162(bash) pid=2010162(bash) ptid=472866(cpufreq-service) cwd= fdlimit=1024 pgft_maj=0 pgft_min=129 vm_size=1824 vm_rss=0 vm_swap=0 comm=bash cgroups=cpuset=/.cpu=/user.slice/user-1000.slice/user@1000.service/session.slice.cpua... env=HOME=/home/REDACTED.LANG=en_CA.UTF-8.LANGUAGE=en_CA:en.LOGNAME=REDACTED.P... tty=0 pgid=472649(gnome-shell) loginuid=1000 flags=0 2407752 07:58:37.805628374 14 cpufreqctl (2010174.2010174) < execve res=-2(ENOENT) exe=bash args=/usr/bin/cpufreqctl.--throttle-events. tid=2010174(cpufreqctl) pid=2010174(cpufreqctl) ptid=472866(cpufreq-service) cwd= fdlimit=1024 pgft_maj=0 pgft_min=123 vm_size=8228 vm_rss=1536 vm_swap=0 comm=cpufreqctl cgroups=cpuset=/.cpu=/user.slice/user-1000.slice/user@1000.service/session.slice.cpua... env=HOME=/home/REDACTED.LANG=en_CA.UTF-8.LANGUAGE=en_CA:en.LOGNAME=REDACTED.P... tty=0 pgid=472649(gnome-shell) loginuid=1000 flags=0 2407826 07:58:37.805685405 14 cpufreqctl (2010174.2010174) < execve res=-2(ENOENT) exe=bash args=/usr/bin/cpufreqctl.--throttle-events. tid=2010174(cpufreqctl) pid=2010174(cpufreqctl) ptid=472866(cpufreq-service) cwd= fdlimit=1024 pgft_maj=0 pgft_min=124 vm_size=8228 vm_rss=1536 vm_swap=0 comm=cpufreqctl cgroups=cpuset=/.cpu=/user.slice/user-1000.slice/user@1000.service/session.slice.cpua... env=HOME=/home/REDACTED.LANG=en_CA.UTF-8.LANGUAGE=en_CA:en.LOGNAME=REDACTED.P... tty=0 pgid=472649(gnome-shell) loginuid=1000 flags=0 2407886 07:58:37.805742646 14 cpufreqctl (2010174.2010174) < execve res=-2(ENOENT) exe=bash args=/usr/bin/cpufreqctl.--throttle-events. tid=2010174(cpufreqctl) pid=2010174(cpufreqctl) ptid=472866(cpufreq-service) cwd= fdlimit=1024 pgft_maj=0 pgft_min=125 vm_size=8228 vm_rss=1536 vm_swap=0 comm=cpufreqctl cgroups=cpuset=/.cpu=/user.slice/user-1000.slice/user@1000.service/session.slice.cpua... env=HOME=/home/REDACTED.LANG=en_CA.UTF-8.LANGUAGE=en_CA:en.LOGNAME=REDACTED.P... tty=0 pgid=472649(gnome-shell) loginuid=1000 flags=0

And this comes up EVERY SECOND.

I had to kill cpufreq-service just to stop my CPU from being hammered by this.

The thing is, when I reboot or powercycle otherwise, this behaviour isn't exhibited.

This clearly is a flaw of cpufreq and I probably now have to alt+f2 then "r" to reload gnome just to get cpufreq going again.

:/ can we get this looked at please?

[BloodyIron]

Yeah so as I'm writing this, cpufreq keeps forking "journalctl" processes and is using 20%+/- 10% of my Ryzen 5800x CPU keeping it perpetually active. And the computer was rebooted earlier today.

I really don't even see how to "nicely" stop this, without rebooting. Which is probably what I'll do.

WTF is going on here?!??!

[K0bin]

I'm having the same problem. cpufreq-service keeps starting journalctl every 2 seconds which keeps cpu clock speeds and fan speeds high.

The service even kept running after I disabled the extension.

[BloodyIron]

I really hope this gets fixed. This is really not okay.

[peci1]

I've identified two lines of code that lead to very frequent process spawns:

This one runs the journalctl:

https://github.com/konkor/cpufreq/blob/master/cpufreq-service#L125

And this one spawns a new thread every second just to read data from file:

https://github.com/konkor/cpufreq/blob/master/cpufreq-service#L368

Commenting out these two lines, I get a much more steady usage of the system. With these lines, after 3 hours of running the system, my PIDs are about 160000 high and growing several tens a second. Most of this is indeed the job of cpufreq. @konkor There has to be a better way to monitor things than spinning up the CPU to just create one-off processes at this pace...

[BloodyIron]

@peci1 shouldn't the "service" itself be doing those things as a dedicated process? Lol that sounds comedic in nature, but also tragic. Such is life. @konkor can we get this improved please?