Core 199 - collectd - cpufreq-plugin floods syslog

Core 199 - collectd - cpufreq-plugin floods syslog

[Matthias Fischer]

Hi,

just in case that this happens to somebody else:

Some days ago I made a fresh install of Core 199 with a new machine and
rather old cpu (i7-2700). Runs fine and has more power than the old Duo
box. Fits my needs.

But I couldn't disable HT in BIOS - 'htop' finds eight CPUs. Should be
no problem - but it is.

The problem came with the 'cpufreq'-plugin, my logs were flooded with
warnings:
"cpufreq plugin: Reading
"/sys/devices/system/cpu/cpu4[5,6,7]/cpufreq/scaling_cur_freq" failed."

Because of the deactivation, 'scaling_cur_freq' was empty, there were
complains about CPU 4-7 (the deactivated ones) and in no time my log was
filled with about 10000 'collectd'-entries.

My solution was to change the loglevel of the 'Plugin syslog' in
'collectd.conf' from 'info' to 'err'.

Can anyone confirm this behaviour?

Best
Matthias

Re: Core 199 - collectd - cpufreq-plugin floods syslog

[Adolf Belka]

Hi Matthias,

On 21/01/2026 21:47, Matthias Fischer wrote:
> Hi,
>
> just in case that this happens to somebody else:
>
> Some days ago I made a fresh install of Core 199 with a new machine and
> rather old cpu (i7-2700). Runs fine and has more power than the old Duo
> box. Fits my needs.
>
> But I couldn't disable HT in BIOS - 'htop' finds eight CPUs. Should be
> no problem - but it is.
>
> The problem came with the 'cpufreq'-plugin, my logs were flooded with
> warnings:
> "cpufreq plugin: Reading
> "/sys/devices/system/cpu/cpu4[5,6,7]/cpufreq/scaling_cur_freq" failed."
>
> Because of the deactivation, 'scaling_cur_freq' was empty, there were
> complains about CPU 4-7 (the deactivated ones) and in no time my log was
> filled with about 10000 'collectd'-entries.
>
> My solution was to change the loglevel of the 'Plugin syslog' in
> 'collectd.conf' from 'info' to 'err'.
>
> Can anyone confirm this behaviour?
Can't confirm it on my system. I have a new mini with a quad core 
celeron. cpufreq-plugin is working fine. No error messages of any kind 
in the collectd system logs since I did my CU199 update and all graphs 
are displaying fine.

Regards,

Adolf.

> Best
> Matthias
>
>

-- 
Sent from my laptop

Re: Core 199 - collectd - cpufreq-plugin floods syslog

[Matthias Fischer]

On 22.01.2026 12:02, Adolf Belka wrote:
> Hi Matthias,

Hi Adolf,

thanks for the feedback! Comments below...

> On 21/01/2026 21:47, Matthias Fischer wrote:
>> Hi,
>>
>> just in case that this happens to somebody else:
>>
>> Some days ago I made a fresh install of Core 199 with a new machine and
>> rather old cpu (i7-2600). Runs fine and has more power than the old Duo
>> box. Fits my needs.
>>
>> But I couldn't disable HT in BIOS - 'htop' finds eight CPUs. Should be
>> no problem - but it is.
>>
>> The problem came with the 'cpufreq'-plugin, my logs were flooded with
>> warnings:
>> "cpufreq plugin: Reading
>> "/sys/devices/system/cpu/cpu4[5,6,7]/cpufreq/scaling_cur_freq" failed."
>>
>> Because of the deactivation, 'scaling_cur_freq' was empty, there were
>> complains about CPU 4-7 (the deactivated ones) and in no time my log was
>> filled with about 10000 'collectd'-entries.
>>
>> My solution was to change the loglevel of the 'Plugin syslog' in
>> 'collectd.conf' from 'info' to 'err'.
>>
>> Can anyone confirm this behaviour?
> Can't confirm it on my system. I have a new mini with a quad core 
> celeron. cpufreq-plugin is working fine. No error messages of any kind 
> in the collectd system logs since I did my CU199 update and all graphs 
> are displaying fine.

The graphs are absolutely ok here, too and if I hadn't take a look at
the logs I wouldn't have noticed. The problem with my machine seems to
be that the cpufreq-plugin tries to read four *empty* files (concerning
the deactivated "HT-cores"). Theses files are empty, and the plugin
doesn't like that...

But as I wrote, setting the syslog-loglevel to 'err' solved it. The
plugin is quiet now and everything else is running fine. ;-)

Best
Matthias

> 
> Regards,
> 
> Adolf.
> 
>> Best
>> Matthias
>>
>>
> 

Re: Core 199 - collectd - cpufreq-plugin floods syslog

[Michael Tremer]

Hello Matthias,

It seems like you are silencing the symptoms here, but I am perfectly happy with that.

Collectd does not seem to receive a lot of development any more and Adolf has pointed it our that any current RCs are not really a release candidate at all any more. So many plugins are not ported and for a long time we have been thinking about replacing it.

I have an implementation on the go which is quite promising, but it is not ready for Core Update 200, yet. I hope it will make it into 201 or 202. That is why I am happy to just leave collectd as it is now and move on.

However, we will need to fix this problem in the new implementation that you can find here:

  https://git.ipfire.org/?p=collecty.git;a=summary

When we introduced a lot of the Meltdown/Spectre measures, we usually disable HT on all systems. Nobody has reported since that this might cause any problems in collecting any of the CPU data. As soon as the new solution is available, please make sure that I got it right please.

-Michael

> On 22 Jan 2026, at 14:04, Matthias Fischer <matthias.fischer@ipfire.org> wrote:
> 
> On 22.01.2026 12:02, Adolf Belka wrote:
>> Hi Matthias,
> 
> Hi Adolf,
> 
> thanks for the feedback! Comments below...
> 
>> On 21/01/2026 21:47, Matthias Fischer wrote:
>>> Hi,
>>> 
>>> just in case that this happens to somebody else:
>>> 
>>> Some days ago I made a fresh install of Core 199 with a new machine and
>>> rather old cpu (i7-2600). Runs fine and has more power than the old Duo
>>> box. Fits my needs.
>>> 
>>> But I couldn't disable HT in BIOS - 'htop' finds eight CPUs. Should be
>>> no problem - but it is.
>>> 
>>> The problem came with the 'cpufreq'-plugin, my logs were flooded with
>>> warnings:
>>> "cpufreq plugin: Reading
>>> "/sys/devices/system/cpu/cpu4[5,6,7]/cpufreq/scaling_cur_freq" failed."
>>> 
>>> Because of the deactivation, 'scaling_cur_freq' was empty, there were
>>> complains about CPU 4-7 (the deactivated ones) and in no time my log was
>>> filled with about 10000 'collectd'-entries.
>>> 
>>> My solution was to change the loglevel of the 'Plugin syslog' in
>>> 'collectd.conf' from 'info' to 'err'.
>>> 
>>> Can anyone confirm this behaviour?
>> Can't confirm it on my system. I have a new mini with a quad core 
>> celeron. cpufreq-plugin is working fine. No error messages of any kind 
>> in the collectd system logs since I did my CU199 update and all graphs 
>> are displaying fine.
> 
> The graphs are absolutely ok here, too and if I hadn't take a look at
> the logs I wouldn't have noticed. The problem with my machine seems to
> be that the cpufreq-plugin tries to read four *empty* files (concerning
> the deactivated "HT-cores"). Theses files are empty, and the plugin
> doesn't like that...
> 
> But as I wrote, setting the syslog-loglevel to 'err' solved it. The
> plugin is quiet now and everything else is running fine. ;-)
> 
> Best
> Matthias
> 
>> 
>> Regards,
>> 
>> Adolf.
>> 
>>> Best
>>> Matthias
>>> 
>>> 
>> 
> 
> 

Core 199 - collectd - cpufreq-plugin floods syslog

[Matthias Fischer]

2cd try:
For reasons unknown to me, my Mails no longer appear on the list, even
though I can send them there without any errors.

Therefore: next attempt - plus CC to MT [Hi Michael... ;-) ]

-----------------

Hi,

just in case that this happens to somebody else:

Some days ago I made a fresh install of Core 199 with a new machine and
rather old cpu (i7-2700). Runs fine and has more power than the old Duo
box. Fits my needs.

But I couldn't disable HT in BIOS - 'htop' finds eight CPUs. Should be
no problem - but it is.

The problem came with the 'cpufreq'-plugin, my logs were flooded with
warnings:
"cpufreq plugin: Reading
"/sys/devices/system/cpu/cpu4[5,6,7]/cpufreq/scaling_cur_freq" failed."

Because of the deactivation, 'scaling_cur_freq' was empty, there were
complains about CPU 4-7 (the deactivated ones) and in no time my log was
filled with about 10000 'collectd'-entries.

My solution was to change the loglevel of the 'Plugin syslog' in
'collectd.conf' from 'info' to 'err'.

Can anyone confirm this behaviour?

Best
Matthias

Re: Core 199 - collectd - cpufreq-plugin floods syslog

[Tom Rymes]

Matthias,

I always get your emails to the list, followed by a second message that your emails aren’t appearing on the list. I’m guessing the issue is that you are not receiving a copy of your own e-mails?

Either way, it always seems to be working properly to me.

Tom

> On Jan 21, 2026, at 5:52 PM, Matthias Fischer <matthias.fischer@ipfire.org> wrote:
> 
> 2cd try:
> For reasons unknown to me, my Mails no longer appear on the list, even
> though I can send them there without any errors.
> 
> Therefore: next attempt - plus CC to MT [Hi Michael... ;-) ]
> 
> -----------------
> 
> Hi,
> 
> just in case that this happens to somebody else:
> 
> Some days ago I made a fresh install of Core 199 with a new machine and
> rather old cpu (i7-2700). Runs fine and has more power than the old Duo
> box. Fits my needs.
> 
> But I couldn't disable HT in BIOS - 'htop' finds eight CPUs. Should be
> no problem - but it is.
> 
> The problem came with the 'cpufreq'-plugin, my logs were flooded with
> warnings:
> "cpufreq plugin: Reading
> "/sys/devices/system/cpu/cpu4[5,6,7]/cpufreq/scaling_cur_freq" failed."
> 
> Because of the deactivation, 'scaling_cur_freq' was empty, there were
> complains about CPU 4-7 (the deactivated ones) and in no time my log was
> filled with about 10000 'collectd'-entries.
> 
> My solution was to change the loglevel of the 'Plugin syslog' in
> 'collectd.conf' from 'info' to 'err'.
> 
> Can anyone confirm this behaviour?
> 
> Best
> Matthias
> 

Re: Core 199 - collectd - cpufreq-plugin floods syslog

[Matthias Fischer]

On 22.01.2026 01:49, Tom Rymes wrote:
> Matthias,

Hi Tom,

> I always get your emails to the list, followed by a second message that your emails aren’t appearing on the list. I’m guessing the issue is that you are not receiving a copy of your own e-mails?

Exactly.

This started "some day" - so that I couldn't tell if my mail came through.

On the other hand, I receive mails like yours always *twice*. Funny. One
of these mails comes with a List-ID from <development.lists.ipfire.org>.
Its a bit weird...

> Either way, it always seems to be working properly to me.

Ok - I think, for the moment I can live with that... ;-)

Best
Matthias

> 
> Tom
> 
>> On Jan 21, 2026, at 5:52 PM, Matthias Fischer <matthias.fischer@ipfire.org> wrote:
>> 
>> 2cd try:
>> For reasons unknown to me, my Mails no longer appear on the list, even
>> though I can send them there without any errors.
>> 
>> Therefore: next attempt - plus CC to MT [Hi Michael... ;-) ]
>> 
>> -----------------
>> 
>> Hi,
>> 
>> just in case that this happens to somebody else:
>> 
>> Some days ago I made a fresh install of Core 199 with a new machine and
>> rather old cpu (i7-2700). Runs fine and has more power than the old Duo
>> box. Fits my needs.
>> 
>> But I couldn't disable HT in BIOS - 'htop' finds eight CPUs. Should be
>> no problem - but it is.
>> 
>> The problem came with the 'cpufreq'-plugin, my logs were flooded with
>> warnings:
>> "cpufreq plugin: Reading
>> "/sys/devices/system/cpu/cpu4[5,6,7]/cpufreq/scaling_cur_freq" failed."
>> 
>> Because of the deactivation, 'scaling_cur_freq' was empty, there were
>> complains about CPU 4-7 (the deactivated ones) and in no time my log was
>> filled with about 10000 'collectd'-entries.
>> 
>> My solution was to change the loglevel of the 'Plugin syslog' in
>> 'collectd.conf' from 'info' to 'err'.
>> 
>> Can anyone confirm this behaviour?
>> 
>> Best
>> Matthias
>> 
> 
> 

Re: Core 199 - collectd - cpufreq-plugin floods syslog

[Michael Tremer]

Hello Matthias,

I think too that your emails are making it to the list just fine. The archive got them too:

  https://lists.ipfire.org/development/7cf06956-d5b8-4769-b020-144737f1da10@ipfire.org/T/#m01f734b0ade53d5f047771ea7cae1c22347b82ad

Since we changed to mlmmj you won’t receive a copy from the list again. Mailman could be configured to send you a copy if your own mail, but since you normally don’t get that when you send a personal email, why would you get that from a list? Just assume your email made it.

If you get them double, this is probably because people are replying to you as well as the list. Like I am doing now. Your email client should be able to deduplicate emails by their ID. Mine would never show the same email twice. Which one are you using?

I would like us all to have a high confidence in this email system working, so if you see any problems, please let me know.

All the best,
-Michael

> On 22 Jan 2026, at 06:32, Matthias Fischer <matthias.fischer@ipfire.org> wrote:
> 
> On 22.01.2026 01:49, Tom Rymes wrote:
>> Matthias,
> 
> Hi Tom,
> 
>> I always get your emails to the list, followed by a second message that your emails aren’t appearing on the list. I’m guessing the issue is that you are not receiving a copy of your own e-mails?
> 
> Exactly.
> 
> This started "some day" - so that I couldn't tell if my mail came through.
> 
> On the other hand, I receive mails like yours always *twice*. Funny. One
> of these mails comes with a List-ID from <development.lists.ipfire.org>.
> Its a bit weird...
> 
>> Either way, it always seems to be working properly to me.
> 
> Ok - I think, for the moment I can live with that... ;-)
> 
> Best
> Matthias
> 
>> 
>> Tom
>> 
>>> On Jan 21, 2026, at 5:52 PM, Matthias Fischer <matthias.fischer@ipfire.org> wrote:
>>> 
>>> 2cd try:
>>> For reasons unknown to me, my Mails no longer appear on the list, even
>>> though I can send them there without any errors.
>>> 
>>> Therefore: next attempt - plus CC to MT [Hi Michael... ;-) ]
>>> 
>>> -----------------
>>> 
>>> Hi,
>>> 
>>> just in case that this happens to somebody else:
>>> 
>>> Some days ago I made a fresh install of Core 199 with a new machine and
>>> rather old cpu (i7-2700). Runs fine and has more power than the old Duo
>>> box. Fits my needs.
>>> 
>>> But I couldn't disable HT in BIOS - 'htop' finds eight CPUs. Should be
>>> no problem - but it is.
>>> 
>>> The problem came with the 'cpufreq'-plugin, my logs were flooded with
>>> warnings:
>>> "cpufreq plugin: Reading
>>> "/sys/devices/system/cpu/cpu4[5,6,7]/cpufreq/scaling_cur_freq" failed."
>>> 
>>> Because of the deactivation, 'scaling_cur_freq' was empty, there were
>>> complains about CPU 4-7 (the deactivated ones) and in no time my log was
>>> filled with about 10000 'collectd'-entries.
>>> 
>>> My solution was to change the loglevel of the 'Plugin syslog' in
>>> 'collectd.conf' from 'info' to 'err'.
>>> 
>>> Can anyone confirm this behaviour?
>>> 
>>> Best
>>> Matthias
>>> 
>> 
>> 
> 
>