snmp-net not working with lm-sensors

[raphael]

I'm trying to get temperature with snmp and lm-sensors but it's not working.

I really think it's bug here's the output of a few commands that may be relevant.

raphael@francois-desktop:~$ sudo snmpwalk -v2c -c public localhost 1.3.6.1.4.1.2021.13.16
LM-SENSORS-MIB::lmSensors = No Such Object available on this agent at this OID

raphael@francois-desktop:~$ sensors
atk0110-acpi-0
Adapter: ACPI interface
Vcore Voltage: +1.34 V (min = +0.85 V, max = +1.60 V)
+3.3 Voltage: +3.22 V (min = +2.97 V, max = +3.63 V)
+5 Voltage: +5.04 V (min = +4.50 V, max = +5.50 V)
+12 Voltage: +12.20 V (min = +10.20 V, max = +13.80 V)
CPU FAN Speed: 1048 RPM (min = 600 RPM)
CHASSIS FAN Speed: 0 RPM (min = 600 RPM)
POWER FAN Speed: 0 RPM (min = 600 RPM)
CPU Temperature: +46.0°C (high = +60.0°C, crit = +95.0°C)
MB Temperature: +36.0°C (high = +45.0°C, crit = +95.0°C)

raphael@francois-desktop:~$ apt-cache show snmpd lm-sensors | grep '\(Package\)\|\(Version\)'
Package: snmpd
Version: 5.4.1~dfsg-12ubuntu7
Package: lm-sensors
Version: 1:3.0.2-2ubuntu4

raphael@francois-desktop:~$ snmpwalk -v1 -c public localhost lmSensors
raphael@francois-desktop:~$

raphael@francois-desktop:~$ ls -l /etc/ | grep sensors
-rw-r--r-- 1 root root 61490 2009-03-12 00:24 sensors3.conf
lrwxrwxrwx 1 root root 18 2010-01-12 17:05 sensors.conf -> /etc/sensors3.conf

ProblemType: Bug
Architecture: i386
Date: Wed Jan 13 10:10:59 2010
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: snmpd 5.4.1~dfsg-12ubuntu7
ProcEnviron:
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-17.54-generic
SourcePackage: net-snmp
Uname: Linux 2.6.31-17-generic i686

[Chuck Short (zulcss)]

If possible can you add an strace output?

Thanks
chuck

[Chuck Short (zulcss)]

It looks like its trying to find the /etc/snmp/snmpwalk.conf file. Is it installed on your machine?

Regards
chuck

[raphael (raphoun)]

No, i dont have this file on my machine.

Regards,

Raphaël

[Chuck Short (zulcss)]

Can you try this on lucid?

thanks
chuck

[Patrick Ruckstuhl (patrick-tario)]

I've got a similar thing on lucid. I think the problem is somewhere related to atk0110-acpi-0
other devices seem to work fine

sensors:

atk0110-acpi-0
Adapter: ACPI interface
Vcore Voltage: +1.07 V (min = +0.85 V, max = +1.60 V)
 +3.3 Voltage: +3.30 V (min = +2.97 V, max = +3.63 V)
 +5 Voltage: +5.07 V (min = +4.50 V, max = +5.50 V)
 +12 Voltage: +12.30 V (min = +10.20 V, max = +13.80 V)
CPU FAN Speed: 932 RPM (min = 600 RPM)
CHASSIS FAN Speed:1614 RPM (min = 600 RPM)
POWER FAN Speed: 0 RPM (min = 600 RPM)
CPU Temperature: +34.0°C (high = +60.0°C, crit = +95.0°C)
MB Temperature: +41.0°C (high = +45.0°C, crit = +95.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Core 0: +25.0°C (high = +57.0°C, crit = +85.0°C)

coretemp-isa-0001
Adapter: ISA adapter
Core 1: +21.0°C (high = +57.0°C, crit = +85.0°C)

coretemp-isa-0002
Adapter: ISA adapter
Core 2: +21.0°C (high = +57.0°C, crit = +85.0°C)

coretemp-isa-0003
Adapter: ISA adapter
Core 3: +21.0°C (high = +57.0°C, crit = +85.0°C)

snmpd

LM-SENSORS-MIB::lmVoltSensorsIndex.1 = INTEGER: 0
LM-SENSORS-MIB::lmVoltSensorsIndex.2 = INTEGER: 1
LM-SENSORS-MIB::lmVoltSensorsIndex.3 = INTEGER: 2
LM-SENSORS-MIB::lmVoltSensorsDevice.1 = STRING: Vcore Voltage
LM-SENSORS-MIB::lmVoltSensorsDevice.2 = STRING: Vcore Voltage
LM-SENSORS-MIB::lmVoltSensorsDevice.3 = STRING: Vcore Voltage
LM-SENSORS-MIB::lmVoltSensorsValue.1 = Gauge32: 1072
LM-SENSORS-MIB::lmVoltSensorsValue.2 = Gauge32: 850
LM-SENSORS-MIB::lmVoltSensorsValue.3 = Gauge32: 1600
LM-SENSORS-MIB::lmMiscSensorsIndex.1 = INTEGER: 0
LM-SENSORS-MIB::lmMiscSensorsIndex.2 = INTEGER: 1
LM-SENSORS-MIB::lmMiscSensorsIndex.3 = INTEGER: 2
LM-SENSORS-MIB::lmMiscSensorsIndex.4 = INTEGER: 3
LM-SENSORS-MIB::lmMiscSensorsIndex.5 = INTEGER: 4
LM-SENSORS-MIB::lmMiscSensorsIndex.6 = INTEGER: 5
LM-SENSORS-MIB::lmMiscSensorsIndex.7 = INTEGER: 6
LM-SENSORS-MIB::lmMiscSensorsIndex.8 = INTEGER: 7
LM-SENSORS-MIB::lmMiscSensorsIndex.9 = INTEGER: 8
LM-SENSORS-MIB::lmMiscSensorsIndex.10 = INTEGER: 9
LM-SENSORS-MIB::lmMiscSensorsIndex.11 = INTEGER: 10
LM-SENSORS-MIB::lmMiscSensorsIndex.12 = INTEGER: 11
LM-SENSORS-MIB::lmMiscSensorsIndex.13 = INTEGER: 12
LM-SENSORS-MIB::lmMiscSensorsIndex.14 = INTEGER: 13
LM-SENSORS-MIB::lmMiscSensorsIndex.15 = INTEGER: 14
LM-SENSORS-MIB::lmMiscSensorsIndex.16 = INTEGER: 15
LM-SENSORS-MIB::lmMiscSensorsDevice.1 = STRING: Core 0
LM-SENSORS-MIB::lmMiscSensorsDevice.2 = STRING: Core 0
LM-SENSORS-MIB::lmMiscSensorsDevice.3 = STRING: Core 0
LM-SENSORS-MIB::lmMiscSensorsDevice.4 = STRING: Core 0
LM-SENSORS-MIB::lmMiscSensorsDevice.5 = STRING: Core 1
LM-SENSORS-MIB::lmMiscSensorsDevice.6 = STRING: Core 1
LM-SENSORS-MIB::lmMiscSensorsDevice.7 = STRING: Core 1
LM-SENSORS-MIB::lmMiscSensorsDevice.8 = STRING: Core 1
LM-SENSORS-MIB::lmMiscSensorsDevice.9 = STRING: Core 2
LM-SENSORS-MIB::lmMiscSensorsDevice.10 = STRING: Core 2
LM-SENSORS-MIB::lmMiscSensorsDevice.11 = STRING: Core 2
LM-SENSORS-MIB::lmMiscSensorsDevice.12 = STRING: Core 2
LM-SENSORS-MIB::lmMiscSensorsDevice.13 = STRING: Core 3
LM-SENSORS-MIB::lmMiscSensorsDevice.14 = STRING: Core 3
LM-SENSORS-MIB::lmMiscSensorsDevice.15 = STRING: C...

[Rob D (rob.d)]

This also affects me: Ubuntu Lucid (10.04), 2.6.32-22-generic #33-Ubuntu SMP

~$ apt-cache show snmpd lm-sensors | grep '\(Package\)\|\(Version\)'
Package: snmpd
Version: 5.4.2.1~dfsg0ubuntu1-0ubuntu2
Package: lm-sensors
Version: 1:3.1.2-2

~$ sensors
smsc47b397-isa-0480
Adapter: ISA adapter
fan1: 2016 RPM
fan2: 0 RPM
fan3: 1226 RPM
fan4: 993 RPM
temp1: +28.0°C
temp2: +21.0°C
temp3: +20.0°C
temp4: +0.0°C

~$ snmpwalk -v1 -c public localhost lmTempSensorsTable
***nothing***

What is interesting is that I do get one data set, just not all of it when I try this:
~$ snmpwalk -v1 -c public localhost lmsensors
LM-SENSORS-MIB::lmFanSensorsIndex.1 = INTEGER: 0
LM-SENSORS-MIB::lmFanSensorsDevice.1 = STRING: fan1
LM-SENSORS-MIB::lmFanSensorsValue.1 = Gauge32: 2017

Previous release worked fine on the same hardware.

[Erik van Elsas (ubuntu-limbels)]

I think the problem in lucid lies in the switch to the libsensors4 API in agent/mibgroup/ucd-snmp/lmSensors.c
Patch 60 replaces the test (data->mapping == SENSORS_NO_MAPPING) with a test for (subfeature->mapping == 0).
In libsensors3, the SENSORS_NO_MAPPING value indicated a new main feature. The subfeature mapping on the other hand indicates the number of the feature it belongs to. So the test only succeeds for (all of the) subfeatures of the first feature. All other features are skipped.

[sygoletto (sygoletto)]

Same hardware, one with Hardy 8.04.3 LTS one with Lucid 10.04, same sensors output but different snmpwalks : missing Core1 Temp.

On 8.04.3 and 10.04:
$ sensors
k8temp-pci-00c3
Adapter: PCI adapter
Core0 Temp: +26.0°C
Core1 Temp: +25.0°C

On 8.04.3:
$ snmpwalk -v2c -cpublic 192.168.0.1 .1.3.6.1.4.1.2021.13.16
LM-SENSORS-MIB::lmTempSensorsIndex.1 = INTEGER: 0
LM-SENSORS-MIB::lmTempSensorsIndex.2 = INTEGER: 1
LM-SENSORS-MIB::lmTempSensorsDevice.1 = STRING: Core0 Temp
LM-SENSORS-MIB::lmTempSensorsDevice.2 = STRING: Core1 Temp
LM-SENSORS-MIB::lmTempSensorsValue.1 = Gauge32: 44000
LM-SENSORS-MIB::lmTempSensorsValue.2 = Gauge32: 42000

On 10.04:
$ snmpwalk -v2c -cpublic localhost .1.3.6.1.4.1.2021.13.16 LM-SENSORS-MIB::lmTempSensorsIndex.1 = INTEGER: 0
LM-SENSORS-MIB::lmTempSensorsDevice.1 = STRING: Core0 Temp
LM-SENSORS-MIB::lmTempSensorsValue.1 = Gauge32: 26000

[Rob D (rob.d)]

@Erik, I am trying to find the change/patch you mention.

The changelog does list the switch to libsensors4, around 2009-11-26?,
https://launchpad.net/ubuntu/lucid/+source/net-snmp/+changelog

For net-snmp 5.4.2.1~dfsg0ubuntu1-0ubuntu2.1 - I see lmSensors.c rev 14 from 2007-12-08
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/net-snmp/lucid-security/files/head:/agent/mibgroup/ucd-snmp/

It still shows the condition (data->mapping == SENSORS_NO_MAPPING)

Am I looking in the right place?

[Erik van Elsas (ubuntu-limbels)]

@Rob.D, I'm not at all an expert on Debian/Ubuntu development, but as far as I understand what you see is the original ("upstream") source tree. Debian/Ubuntu applies patches on this source if necessary. The patch I mentioned can be seen at http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/net-snmp/lucid-security/annotate/head:/debian/patches/60_libsensors_api.patch

[Brad Cowie (bradcowie)]

I had the same issue with my fresh install of ubuntu 10.04 server.

There is a patch in the debian bug system that fixes this issue: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575810

I applied the patch and rebuild the ubuntu package from source and I get all of my sensor data now.

[Brad Cowie (bradcowie)]

I had a request to build some custom debs with the debian patch from the debian bug report.

So you can find those here: http://wand.net.nz/~bmc26/debs/net-snmp/

[batsi (tiacjesus)]

Thanks Brad for your builds, worked like a charme.
That patch should find its way to the stable repository soon.

[Chuck Short (zulcss)]

Ok this patch has been applied to maverick. Its porbably a good candidate for an sru.

chuck

[undefined (undefined)]

i believe that the patch for net-snmp debian bug #575810 should have included:

-+ (subfeature->mapping == 0) &&
++ (subfeature->type == (feature->type << 8)) &&

i agree with the bug report that "subfeature->mapping == 0" causes snmpd to only report the first feature, but the suggested/accepted patch causes all subfeatures of all features to be reported, which is definitely not the historical (ie debian lenny & ubuntu hardy) behavior of snmpd.

now every subfeature (eg fan1_input, fan1_min, fan1_div & fan1_alarm) of every feature (eg fan1) is reported, and to a casual observer they are indistinguishable in the snmpd output because they are only identified with the feature's name (eg "fan1"; ie "label = sensors_get_label(chip, feature)").

what i believe was intended by the original code (ie "subfeature->mapping == 0") was that only the first subfeature of each feature would be reported (eg fan1_input), because that's the historical output of snmpd and the primary output of the sensors command (eg the other subfeatures are printed following fan1_input and within parens).

a quick "hack" to enable that functionality is "subfeature->type == (feature->type << 8)". this is based off how sensors.h (lines 148-204) spaces the subfeatures (line 148: "All the sensor types (in, fan, temp, vid) are a multiple of 0x100 apart") and how that is based off the associated feature (line 151: "SENSORS_SUBFEATURE_IN_INPUT = SENSORS_FEATURE_IN << 8").

a more thorough patch would probably be logic similar to the sensors command (ie for every feature [fan1] query what type it is [SENSORS_FEATURE_FAN] and pull the appropriate subfeature by name [SENSORS_SUBFEATURE_FAN_INPUT]), but that patch is much more invasive, though it would also eliminate the imperfect guessing of feature type by label (ie lmSensors.c, lines 973-996; eg "if (strstr(label, "V")) type = VOLT_TYPE;").

the attached files show the "bad" snmpwalk output of the proposed (and apparently accepted in maverick) patch and the "good" snmpwalk output of my proposed patch (which is also attached as a patch to 60_libsensors_api.patch).

[Luke Pascoe (luke-pascoe)]

Any idea if/when this fix will be available for 10.04 LTS?

[Kyle Gordon (kylegordon)]

Can anyone provide any info? Is there anybody with ownership of this bug?

[undefined (undefined)]

@Kyle Gordon

the problem is that:

 * this bug is marked as "fix released", so no one is going to pay much attention to the continuing discussion
 * the "released" "fix" has NOT been released for lucid, but i don't see any way to clarify that in this bug report's metadata

i don't see any possible solutions except:

 * raise more stink here in the bug report
 * email the ubuntu package maintainers about the problem
 * patch the package yourself.

in my case, where the "released" "fix" just changes the brokenness, but doesn't really fix it, the situation is even less hopeful:

 * i can't open a new bug against the broken "fix" (proposing my above patch and trying to get this bug more visibility) because the fix hasn't been released yet for lucid (ie nobody will care about a bug report for an unreleased package version)
 * i've even reported the problem to debian's net-snmp packaging team (http://lists.alioth.debian.org/pipermail/pkg-net-snmp-devel/2010-November/001007.html) to which no one responded, so it appears nobody (debian or ubuntu) cares

i'm just building my own net-snmp packages for lucid with my patch and will do the same when the equivalent "fixed" package is released in debian squeeze (i have ubuntu desktops and debian servers; it won't be the first time i've supported my own package version due to unresponsive package maintainers). i've had good success with debian & ubuntu net-snmp maintainers in the past (http://bugs.debian.org/274624 & https://lists.ubuntu.com/archives/lucid-changes/2010-June/011350.html), but nobody seems to be paying attention this time.

i feel sorry for users who are unable to patch & build their own package versions.

[Dennis Borgmann (dennis-borgmann)]

hi guys!

i just installed mythbuntu on my HTPC (mythbnutu version 11.10) and this is the output of sensors:

root@fernseher-PC:/home/fernseher# sensors
atk0110-acpi-0
Adapter: ACPI interface
Vcore Voltage: +1.04 V (min = +0.85 V, max = +1.60 V)
 +3.3 Voltage: +3.28 V (min = +2.97 V, max = +3.63 V)
 +5 Voltage: +5.12 V (min = +4.50 V, max = +5.50 V)
 +12 Voltage: +12.15 V (min = +10.20 V, max = +13.80 V)
CPU FAN Speed: 2115 RPM (min = 600 RPM)
CHASSIS FAN Speed: 0 RPM (min = 600 RPM)
POWER FAN Speed: 0 RPM (min = 600 RPM)
CPU Temperature: +32.0°C (high = +60.0°C, crit = +95.0°C)
MB Temperature: +35.0°C (high = +45.0°C, crit = +75.0°C)

k10temp-pci-00c3
Adapter: PCI adapter
temp1: +21.4°C (high = +70.0°C)
                       (crit = +99.5°C, hyst = +97.5°C)

therefore it seems like the problem still exists. I only get the fan speed of the cpu-fan. if i understand this thread correctly, there has been a patch to this bug, but it was never applied the way it should have been(see the last posting previous to this one by "undefined (undefined) wrote on 2011-01-16:".

therefore: is it true, that this problem is still existent and if so, how would i be able to correct it?

[undefined (undefined)]

@Dennis Borgmann

no, the behavior you are seeing is not related to this bug report.

to review, this bug report documents two bugs (with the second bug caused by the patching of the first bug):
1. lmsensors data is not available through snmp
2. snmp returns lmsensors information, but instead of returning the first subfeature (fan1_input) of each feature (fan1), as before, it returns all subfeatures (fan1_input, fan1_min, fan1_div & fan1_alarm) and with only one label (ie "fan1").

so the bugs are in net-snmp, not lmsensors. the fact that you are having problems with the sensors command, from lmsensors, convinces me <jedi>these aren't the bugs you're looking for</jedi>.