Collectd : cpufreq plugin: Reading failed. Logging questions

Due to a previous topic about logs when upgrading IPFire I have dug in to those a bit more than usual.

The upgrade to 199 went well, but I am curious about a few issues I do not find an explanation to.

  1. System collectd: seems to be gathering a HUGE amount of logs like these, and has for a long time:
    cpufreq plugin: Reading "/sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq" failed.
    How to turn off? There is a quarter of a million entries for February alone, serving zero purpose AFAIK. I have no CPUFreq plugin installed, at least it is not on the list of installed plugins.

  2. Why is there still a Zabbix agent log? I have removed that plugin after decommissioning my attempt at Zabbix.


    Or was it there all the time? It has many old entries, would like that to be gone with the removal of the plugin. Maybe it does not remove itself and one has to do manual labour to get rid of it?

  3. Where do you set a global logging limitation? I have no need for 30322 collectd cpufreq log entries from august 2025. Or 6946 Zabbix logs from september 2025 and onwards. The log summary setting is unclear, what does it limit? www.ipfire.org - Log Settings it is said to limit logging, but it does not seem to do that.

Admittedly someone feels all this logging is needed, I just want it to be relevant and controlled by a time span. No, my drives are not filling up yet, well yes they do, but I have 420268MB to spare, it is shrinking though…

It was there all the time, just the same as NUT, APCUPS, ClamAV, Samba etc. They are always listed in the System Logs drop down box.

If you don’t have any of those addons then you get an empty log for any time entry that you select.

If you used to have one of them installed then you will still be able to see the logs from when they were running for a year after uninstalling it. No new logs will be created after the addon is uninstalled.

I also see the Zabbix entry on my production IPFire System Logs. If I select it for a whole month, then irrespective of which month I select I get an empty log as I have never used Zabbix on that system (yet).

This is not referring to the cpufreq addon, which was removed back in CU197, it is referring to the collectd cpufreq plugin that collects data on the number of cpu cores you have and provides the graph that shows the frequency that each core is running at in your WUI.

Maybe the collectd cpufreq plugin is having problems with your specific cpu.

Hi,

as stated here I had the same problem.

“My solution was to to change the loglevel of the ‘Plugin syslog’ in ‘collectd.conf’ from ‘info’ to ‘err’.”

HTH

Matthias

2 Likes

Well the CPU is Xeon E3-1245 v5 (Skylake, 4C/8T, 3.5 GHz base, with iGPU)

Based on that suggestion I and Claude AI started a session diagnosing this and trying to fix and clean… this is bloat.

Collectd cpufreq flood — resolution log

  1. Located collectd config at /etc/collectd.conf
  2. Confirmed LoadPlugin cpufreq was explicitly loaded
  3. Identified root cause: /sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq returns “Device or resource busy” — kernel level, unfixable
  4. Considered changing Plugin syslog LogLevel from info to err (per IPFire dev mailing list recommendation) — rejected because it would silence INFO messages from all other collectd plugins (cpu, disk, memory, interface, etc.)
  5. Chose surgical fix: disabled cpufreq plugin only by commenting it out
   sed -i 's/^LoadPlugin cpufreq/#LoadPlugin cpufreq/' /etc/collectd.conf
  1. Restarted collectd via SysVinit (IPFire doesn’t use systemd):
   /etc/rc.d/init.d/collectd restart
  1. Purged 8185 cpufreq log lines from /var/log/messages while preserving all other content:
   grep -v "cpufreq" /var/log/messages > /tmp/messages_clean && mv /tmp/messages_clean /var/log/messages
  1. Restored file permissions: chmod 664 /var/log/messages
  2. Result: 0 cpufreq info entries, file reduced from 4.1MB → 3.1MB
  3. Zero effect on other plugin logging.

Zabbix

A real pain to find, well not really:

  1. Claude:
for f in /var/log/messages.*.gz; do
    count=$(zcat "$f" | grep -c "zabbix" 2>/dev/null)
    [ "$count" -gt 0 ] && echo "$f: $count hits"
done

/var/log/messages.10.gz: 81619 hits
/var/log/messages.11.gz: 81656 hits
/var/log/messages.12.gz: 81654 hits
/var/log/messages.13.gz: 81654 hits
/var/log/messages.14.gz: 81589 hits
/var/log/messages.15.gz: 81351 hits
/var/log/messages.16.gz: 81656 hits
/var/log/messages.17.gz: 82134 hits
/var/log/messages.18.gz: 81547 hits
/var/log/messages.19.gz: 81648 hits
/var/log/messages.20.gz: 78669 hits
/var/log/messages.21.gz: 50760 hits
/var/log/messages.22.gz: 59045 hits
/var/log/messages.23.gz: 77204 hits
/var/log/messages.24.gz: 27533 hits
/var/log/messages.25.gz: 113 hits
/var/log/messages.6.gz: 16688 hits
/var/log/messages.7.gz: 67775 hits
/var/log/messages.8.gz: 67760 hits
/var/log/messages.9.gz: 76910 hits

Yeah, I don’t wanna keep any of that.
Even Claude reacted with a “Good lord!?”

  1. I decide to nuke all affected, since I have no need for them anyways.
    rm /var/log/messages.{6..25}.gz && ls /var/log/messages*
  2. For those wanting a more surgical clean, keeping the logs, well good luck with that.

After some checks in the WUI I am happy with result and see no other logs being affected by this prune.

Global logging limits

  • postponed due to complexity and getting bored with this.

Hi,

how are the side effects on the processor and system graphs of your system?

For me, disabling the cpufreq plugin resulted in empty graphs.

They work, that is why I was careful with limiting my exclusion.


I do not want to cripple other functions.

From what you wrote, you did not disable the cpufreq, you changed the entire logging verbosity from info to warning. That probably killed you other tables as well.

Hi,

ok, I think we misunderstood each other.

Especially the frequency graphs were missing after I disabled the cpufreq plugin, not because I changed the loglevel.

Important: I also adjusted the start section of the init script for ‘collectd’ so that the plugin would not be automatically reactivated - I commented the affected lines:

# Enable cpufreq plugin if cpufreq found
# if [ ! -e  /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq ]; then
# sed -i -e “s|^LoadPlugin cpufreq|#LoadPlugin cpufreq|g” /etc/collectd.conf
# else
# sed -i -e “s|^#LoadPlugin cpufreq|LoadPlugin cpufreq|g” /etc/collectd.conf
# fi

As soon as I did this and restarted ‘collectd’, the frequency graphs turned white, no more frequencies were recorded. After changing only the loglevel, everything was ok and the graphs were still updated and displayed.