Sensors Daemon in Ipfire

With one of my last rat eaten, open gate, (drive-through-cpu) Intel firewalls replaced, I have a trivial issue with the sensors daemon in Ipfire on the new firewall hardware.

It is well known that the sensors “ALARMS” are mopstly and usually always incorrect or false positive, except for CPU temps that usually work reasonably reliably.

However, the problem is that sensors trigers the built in ALARM on the mobo, once all the sensors are in status “ALARM”. To note ALL theses alarms are false positive. There uis no overheating and no voltages dropped top zero. The firewall works perfectly.

I need to uninstall sensors on IPFIRE as I cannot manage to find the usual daemon in init.d to stop the sensord daemon.

QUESTION:
Since IPFIRE does not have apt (understandable !) and very little default sysadmin tools (not even whereis among others) -again understandably, I need to know what the easiest way is to find and remove the sensors daemon so that the alarm is not triggered as all the errors are utterly bogus.

Here is an example of the current state. In a day it will all be set to “ALARM” and the Alarm on the mobo will sound. --annoying.

coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +38.0C  (crit = +100.0C)
Core 1:       +40.0C  (crit = +100.0C)

w83627dhg-isa-0000
Adapter: ISA adapter
Vcore:         1.16 V  (min =  +0.72 V, max =  +1.39 V)
in1:           1.05 V  (min =  +0.94 V, max =  +1.16 V)
AVCC:          3.31 V  (min =  +2.96 V, max =  +0.00 V)  ALARM
+3.3V:         3.31 V  (min =  +1.62 V, max =  +3.58 V)
in4:           1.53 V  (min =  +1.35 V, max =  +0.00 V)  ALARM
in5:           1.28 V  (min =  +1.13 V, max =  +1.38 V)
in6:           1.87 V  (min =  +1.62 V, max =  +2.00 V)
3VSB:          3.31 V  (min =  +2.96 V, max =  +3.63 V)
Vbat:          3.07 V  (min =  +2.96 V, max =  +1.25 V)  ALARM
fan1:           0 RPM  (min = 10546 RPM, div = 128)  ALARM
fan2:           0 RPM  (min = 10546 RPM, div = 128)  ALARM
fan3:           0 RPM  (min = 10546 RPM, div = 128)  ALARM
fan4:           0 RPM  (min =    0 RPM, div = 128)  ALARM
fan5:           0 RPM  (min = 10546 RPM, div = 128)  ALARM
temp1:        +46.0C  (high = +75.0C, hyst = +70.0C)  sensor = thermistor

As an example here

sensors is run by collectd as a plugin.

collectd has a conf file /etc/collectd.conf and this has line 27 LoadPlugin sensors

Maybe if you comment out this line and restart collectd it will no longer use lm-sensors but I am not certain and maybe other parts of collectd will then no longer work.
It would be good to test this on a vm system before trying on a production system in case it stops too many things from working.

If it does work you will probably need to redo the edit when an update is run as likely collectd.conf will be overwritten with the default file.

The sensors binary is in /usr/bin/sensors

1 Like

Thanks for the response. Yes I obviously know where the binary is, but was wondering if there were not a daemon.
If there is no sensors daemon (I think it is called sensord in Debian) and no persistent sensors program, then my problem should be somewhere else.

Since posting this message the invalid bogus errors have been creeping to the following laughable bogus state.

coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +38.0C  (crit = +100.0C)
Core 1:       +39.0C  (crit = +100.0C)

w83627dhg-isa-0000
Adapter: ISA adapter
Vcore:         1.16 V  (min =  +0.72 V, max =  +1.39 V)
in1:           1.05 V  (min =  +0.94 V, max =  +1.16 V)
AVCC:          3.31 V  (min =  +2.96 V, max =  +0.00 V)  ALARM
+3.3V:         3.31 V  (min =  +1.62 V, max =  +3.58 V)
in4:           1.53 V  (min =  +1.35 V, max =  +0.00 V)  ALARM
in5:           1.28 V  (min =  +1.13 V, max =  +1.38 V)
in6:           1.87 V  (min =  +1.62 V, max =  +0.62 V)  ALARM
3VSB:          3.31 V  (min =  +2.96 V, max =  +3.63 V)
Vbat:          3.07 V  (min =  +2.96 V, max =  +1.25 V)  ALARM
fan1:           0 RPM  (min = 10546 RPM, div = 128)  ALARM
fan2:           0 RPM  (min = 10546 RPM, div = 128)  ALARM
fan3:           0 RPM  (min = 10546 RPM, div = 128)  ALARM
fan4:           0 RPM  (min =    0 RPM, div = 128)  ALARM
fan5:           0 RPM  (min = 10546 RPM, div = 128)  ALARM
temp1:        +46.0C  (high = +75.0C, hyst = +70.0C)  sensor = thermistor

If I hot boot the machine (power remains on), it all resets magically again … impossible. Clearly a software issue.
lmsensors loads kernel modules so I guess I will have to find those modules and unload them.

The only value of the sensors state and its relevant programs are largely “Server Humor” in my opinion.

The maximum is less than the minimum … go figure !
“New math” ???

1 Like

Luckily there are minimal sysadmin commands in IPFIRE that just happens to be usable.

So here are the kernel modules that are used to log the bogus errors.

Now follows a summary of the probes I have just done.


Driver `coretemp':
  * Chip `Intel digital thermal sensor' (confidence: 9)

Driver `w83627ehf':
  * ISA bus, address 0xca0
    Chip `Winbond W83627DHG Super IO Sensors' (confidence: 9)

Driver `to-be-written':
  * ISA bus
    Chip `IPMI BMC KCS' (confidence: 8)

Note: there is no driver for IPMI BMC KCS yet.
Check https://hwmon.wiki.kernel.org/device_support_status for updates.

The bogus errors are all related to the Driver `w83627ehf’:, which is most likely rat eaten. I am pretty sure that the trouble will stop if I uninstall it. Hopefully insmod and its reciprocal is installed in ipfire.
I will try it and report back.

However, further, there seems to be no driver for `IPMI BMC KCS’ and therefore everything will be misreported … sheesh. Would think that if a driver is missing, a program wont report the data it is supposed to gather from the driver. So there must be some kernel daemon of unknown name that creates the alarm (beep) as I cannot find an external daemon. Clearly every report will fail and such a daemon will sound the mobo alarm.

Now it is just a question of HOW to stick a fork in it, and where and how to find the “IT” I need to stick the fork in. I guess a good start is to unload `w83627ehf’.

I did

lsmod |grep -i w83627ehf

and it reported the driver/module is present.

I removed it

rmmod w83627ehf

and then all the stupid bogus data disappeared and I am left with only what works. Namely the CPU temperatures. Great !

coretemp-isa-0000
Adapter: ISA adapter
Core 0:       +38.0C  (crit = +100.0C)
Core 1:       +40.0C  (crit = +100.0C)

Compared to my initial post, this is way better. No “New Math” alarm triggers anymore.

So I will wait for a few days and see if the alarm comes on. Usually within 24hours after boot. So I will wait two days, and if none at two days then problem should be solved.

1 Like

The last time lm-sensors was updated in IPFire was April 2021 and that version was released in October 2019.

Looking through the code tarball the w83627ehf driver was added into lm-sensors in 2005 and the last change was made in sensors-detect in 2008 to “Fix SMBus detection of W83627EHF and W83627DHG”

I would suspect that the motherboard is doing something different with the sensors data that the linux driver is not understanding.

If you believe that it is a fault with the kernel driver then you could always raise a bug for it on the kernel bugzilla.

EDIT:
An additional commit was made for the w83627ehf driver in lm-sensors in 2012 but was not mentioned in the changes log.
“Increase default value of Vbat max, the previous default triggered an alarm on many boards.”

1 Like

Thanks Adolf.
I just removed the Module and problem basically solved. It definitely read the motherboard wrong as the values returned are unscientific to put it lightly.
I will give it another day or so to make sure it is really solved.

There is no cron or init type rc.local functionality in ipfire. I can copy sources over to ipfire and install, but wonder if there is a native way to run a script at startup ?

Use /etc/sysconfig/rc.local

Is the /etc/rc.local not valid anymore ?
I never noticed that it now resides in sysconfig.

Entered my script in rc.local, but it did not ecexcute after reboot.
So it seems that /etc/sysconfig/rc.local is not read at boot on ipfire at all.
If I execute /etc/sysconfig/rc.local manually then it calls my script and unloads the module.
Anyway,
Is there any cron daemon in any of the pakfire add-ons ? Cron is not listed there. Cron always works for me and
solves all these hickups with rc.local fast. And yes, I did give execution permissions etc.

Since the advent of systemD(uh) things are severely broken. rc.local barely works with systemD. In fact ipfire should rather not use systemD as it is new buggy suspicious software that is not mature enough for a firewall.

It does luckily seem as if you do not use systemD in ipfire which is great if true. I could not find a daemon running or any sign of an executable. So the rc.local issue must be somewhere else this time.

# find |grep -i systemd
./usr/share/vim/vim82/indent/systemd.vim
./usr/share/vim/vim82/syntax/systemd.vim
./usr/share/vim/vim82/ftplugin/systemd.vim
# ps -A |grep -i systemd



Regarding the original issue.
The w83627ehf driver is clearly the issue and has a bug.

The problem was solved when I unload this driver. i have no more false positive voltage failure alarms and false overheating alarms at all after 2 days uptime.
So the original issue has been solved

1 Like

/etc/sysconfig/rc.local is symlinked to /etc/rc.d/rc3.d/S98rc.local so that should run on startup.
rc.local on my machine is already executable and owner/group root so you shouldn’t have needed to change the ownership or the permissions, just add your script code into it.

rc.local has been in /etc/sysconfig/ in IPFire since 2007.

No because fcron is a core component of IPFire.

IPFire2.x uses sysvinit
IPFire3.x will use systemd

2 Likes

That’s a real pity and will make ipfire less secure.