Description of problem:My logs are filling up with nonsensical ALARM notices due to bad min/.max Both syslog and messages logs are filling up with lines like May 23 00:57:31 tunnel sensord: Chip: nct6793-isa-0290 May 23 00:57:31 tunnel sensord: Adapter: ISA adapter May 23 00:57:31 tunnel sensord: in0: +0.37 V (min = +0.00 V, max = +1.74 V) May 23 00:57:31 tunnel sensord: in1: +1.00 V (min = +0.00 V, max = +0.00 V) [ALARM] May 23 00:57:31 tunnel sensord: in2: +3.39 V (min = +0.00 V, max = +0.00 V) [ALARM] May 23 00:57:31 tunnel sensord: in3: +3.38 V (min = +0.00 V, max = +0.00 V) [ALARM] May 23 00:57:31 tunnel sensord: in4: +1.01 V (min = +0.00 V, max = +0.00 V) [ALARM] May 23 00:57:31 tunnel sensord: in5: +0.14 V (min = +0.00 V, max = +0.00 V) [ALARM] May 23 00:57:31 tunnel sensord: in6: +1.02 V (min = +0.00 V, max = +0.00 V) [ALARM] May 23 00:57:31 tunnel sensord: in7: +3.39 V (min = +0.00 V, max = +0.00 V) [ALARM] May 23 00:57:31 tunnel sensord: in8: +3.22 V (min = +0.00 V, max = +0.00 V) [ALARM] May 23 00:57:31 tunnel sensord: in9: +1.03 V (min = +0.00 V, max = +0.00 V) [ALARM] May 23 00:57:31 tunnel sensord: in10: +1.02 V (min = +0.00 V, max = +0.00 V) [ALARM] May 23 00:57:31 tunnel sensord: in11: +1.02 V (min = +0.00 V, max = +0.00 V) [ALARM] May 23 00:57:31 tunnel sensord: in12: +1.01 V (min = +0.00 V, max = +0.00 V) [ALARM] May 23 00:57:31 tunnel sensord: in13: +1.00 V (min = +0.00 V, max = +0.00 V) [ALARM] May 23 00:57:31 tunnel sensord: in14: +1.44 V (min = +0.00 V, max = +0.00 V) [ALARM] Those are clearly totally nonesensical min and max values. This does not appear to be doing any harm, except over 50% of both logs are lines like those. And also the systemd journals are full of those. How do I get rid of them? Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce:Install lm_sensord. Watch the logs fill up with chaff. 1. 2. 3.
It is a standard type dump which indicates you need to configure the alarms for that chip. Preferably in a whatever.conf file in /etc/sensors.d Snippet from mine $ head -17 /etc/sensors.d/xx__lm_sensor.conf #************************************************************************** # Creates /etc/sensors.d/xx__lm_sensor.conf to override any /etc/sensors3.conf settings # Created by /local/bin/gen_lm_sensor Tue 26 Feb 11:11 2019 #************************************************************************** chip "k10temp-*" label temp1 "Radeon CPU" chip "it8721-*" set in0_min 3.04 set in0_max 3.07 ignore in0 set in1_min 2.80 set in1_max 3.00 set in2_min 2.21
CC: (none) => bittwister2
sensors-detect is what is supposed to set up the lm_sensors stuff, not the user, who in general has no idea whatsoever as to what is supposed to go into there or where it is supposed to go (eg mageia has no /etc/sensors.d directory) Ie, this is a bug, whether in Mageia or, more likely, upstream.
> sensors-detect is what is supposed to set up the lm_sensors stuff, not the user I disagree. Just like the user, sensors-detect has no idea what the min/max settings are let alone what the chip's pin is hooked to on the circuit board. Setting those "nonsensical" values creates the ALARM to get the System Admain's attention that there are some configuration settings to be made. > who in general has no idea whatsoever ...... That is the responsibility of the sysadmin to read the documentation and decide what to set where with what. The general rule about .d/ directories are that they are optional. They are the place for the user to place their files with their desired settings. Since the .d/ directory is optional, and there are no default files to place there, I agree with the packager's decision to not create an empty .d/ directory. If I were screener the bug would be closed as Invalid because it has always worked this way for undefined inputs and works as designed. If you want it changed, make a enhancement request at https://github.com/groeck/lm-sensors
Sysadmin? Many (most) Mageia installations have the user the sysadmin. Ie, this is not an enterprize computer system. One of Mageia's selling points is precisely its ability to set up the system so that it is usable out of the box. If sensors-detect does not know what to put into some place, it should say so, and disable that particular sensor, not put in nonsense values to flood the logs as a message that "something" is wrongi (without any clue as to what is wrong or how to fix it). I still say that this is a bug, not a feature, and if it is working to design, then it is a bad/buggy design. It is as if Windows developers stated that the "Blue Screen of Death" was a not a bug, but was put there to tell the user something was wrong (withoug of course giving any clue as to what is wrong). But if Mageia decides that you are right, there is little I can do about it. And as I said, this may well be an upstream problem about which Mageia also can do little about it.
Assigning to the lm_sensors maintainer, and CC'ing the kernel and drivers maintainers (because this package belongs to the "System/Kernel and hardware" group) for them to tell whether this is something Mageia can address, or whether it's an upstream issue, or...
CC: (none) => kernel, marja11Assignee: bugsquad => peter.semiletov
w unruh, did you run sensors-detect?
Yes I certainly did. Many times.
This one is INVALID. @w unruh: please read the lm-sensors documentation, where it is clearly stated that the user need to configure the sensors if his motherboard/hardware is not already in the database. "Because every motherboard is different, the drivers always advert the measurements at their pins. This means that the values they report are not always immediately relevant to you. They have to be labelled properly, and sometimes they must be scaled to correspond to real-world values." lm-sensors even provide sample configs which can help you to configure your sensors as needed. As this is no configuration which can be done by Mageia (it's the users/admins job) this bug is INVALID.
Resolution: (none) => INVALIDStatus: NEW => RESOLVED