From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [IPv6:::1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4dxn771RTlz3320 for ; Thu, 22 Jan 2026 16:48:03 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519) (Client CN "mail01.haj.ipfire.org", Issuer "R12" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4dxn714Np8z2xdr for ; Thu, 22 Jan 2026 16:47:57 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4dxn7058WPz3D3; Thu, 22 Jan 2026 16:47:56 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1769100476; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1HkjM5fzB4lucRmTwD0KtDQP9kPvmRPZxRC121CYQzw=; b=KvFQUwkiICFnrwX7bhcVWyz5ggs8xHDo9eA30BHjJO0nwW8qie3cX3vXLOv1gRPY2DWx2D /usFzrmTqVTjEICQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1769100476; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1HkjM5fzB4lucRmTwD0KtDQP9kPvmRPZxRC121CYQzw=; b=IGJfinaQQYPXt5pIS2VaGNHL4zO1HlbEiyEuolpSPqS7mFuopEfDPCTw1BjeeXVPeLt0iS 0VmoGR9H/g+S2CK1FakZ2OpM9byFTrjsf0/zoJE//W89eA1wIdjQpBCbiMmCzYdkJmOb2Q EiQbcUQHp0UQmWY7gw02XQ1rrbd+7biVayQlWv4hSSlNVA808N48I48jY6jPjs4dDKpsY0 lPI1DBD7zfbvSRJTp/QRBKoHo9yz4i80zkWPLmpQ1sfV9VfT97fdTbV4jCOvSgCvH6rkSJ MR4SBeLo4H12aqvPvpIvUaWxmBbtjoGvKozmzsKMhaqgdpioekBMbostlIXOhw== Content-Type: text/plain; charset=us-ascii Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: Core 199 - collectd - cpufreq-plugin floods syslog From: Michael Tremer In-Reply-To: <7cf06956-d5b8-4769-b020-144737f1da10@ipfire.org> Date: Thu, 22 Jan 2026 16:47:56 +0000 Cc: Adolf Belka , "IPFire: Development-List" Content-Transfer-Encoding: quoted-printable Message-Id: <04D3CAB9-E50A-49C1-8E76-2FE47688D4AF@ipfire.org> References: <112b1abc-5ac6-4e52-8fe8-0112ab8a7607@ipfire.org> <7cf06956-d5b8-4769-b020-144737f1da10@ipfire.org> To: Matthias Fischer 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=3Dcollecty.git;a=3Dsummary 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 = wrote: >=20 > On 22.01.2026 12:02, Adolf Belka wrote: >> Hi Matthias, >=20 > Hi Adolf, >=20 > thanks for the feedback! Comments below... >=20 >> On 21/01/2026 21:47, Matthias Fischer wrote: >>> Hi, >>>=20 >>> just in case that this happens to somebody else: >>>=20 >>> 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. >>>=20 >>> But I couldn't disable HT in BIOS - 'htop' finds eight CPUs. Should = be >>> no problem - but it is. >>>=20 >>> 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." >>>=20 >>> 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. >>>=20 >>> My solution was to change the loglevel of the 'Plugin syslog' in >>> 'collectd.conf' from 'info' to 'err'. >>>=20 >>> Can anyone confirm this behaviour? >> Can't confirm it on my system. I have a new mini with a quad core=20 >> celeron. cpufreq-plugin is working fine. No error messages of any = kind=20 >> in the collectd system logs since I did my CU199 update and all = graphs=20 >> are displaying fine. >=20 > 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... >=20 > But as I wrote, setting the syslog-loglevel to 'err' solved it. The > plugin is quiet now and everything else is running fine. ;-) >=20 > Best > Matthias >=20 >>=20 >> Regards, >>=20 >> Adolf. >>=20 >>> Best >>> Matthias >>>=20 >>>=20 >>=20 >=20 >=20