-
Type:
Incident report
-
Resolution: Cannot Reproduce
-
Priority:
Major
-
None
-
Affects Version/s: 1.8.1
-
Component/s: Server (S)
-
None
-
Environment:Solaris 10, Zabbix 1.8.1 compiled against Oracle 10g and NET-SNMP version: 5.4.2, Oracle 11g backend
I see a connection string that appears to have the port 2x:
18394:20100216:170650.346 SNMP [[email protected]:161:161]
Here's a debuglevel 4:
18394:20100217:101450.759 In substitute_simple_macros (data:'powersupply.1.status')
18394:20100217:101450.759 In get_value() key:'powersupply.1.status'
18394:20100217:101450.759 In get_value_snmp() key:'powersupply.1.status' oid:'1.3.6.1.4.1.9.9.13.1.5.1.3.1'
18394:20100217:101450.759 In snmp_open_session()
18394:20100217:101450.759 SNMP [[email protected]:161:161]
18394:20100217:101450.760 End of snmp_open_session()
18394:20100217:101450.760 Standard processing
18394:20100217:101450.760 In snmp_normalize(oid:1.3.6.1.4.1.9.9.13.1.5.1.3.1)
18394:20100217:101450.760 End of snmp_normalize():1.3.6.1.4.1.9.9.13.1.5.1.3.1
18394:20100217:101450.760 In get_snmp(oid:1.3.6.1.4.1.9.9.13.1.5.1.3.1)
18394:20100217:101450.760 Status send [1]
18394:20100217:101450.760 End of get_snmp():NOTSUPPORTED
18394:20100217:101450.761 In snmp_close_session()
18394:20100217:101450.761 End of snmp_close_session()
18394:20100217:101450.761 End of get_value_snmp():NOTSUPPORTED
18394:20100217:101450.761 Item [Hosted-6513-1:powersupply.1.status] error: SNMP error [1]
18394:20100217:101450.761 In zabbix_log()
18394:20100217:101450.761 In DCconfig_get_items() hostid:0 key:'zabbix[log]'
18394:20100217:101450.762 End of DCconfig_get_items():0
18394:20100217:101450.762 End of zabbix_log()
18394:20100217:101450.762 End of get_value():NOTSUPPORTED
18394:20100217:101450.763 Parameter [Hosted-6513-1:powersupply.1.status] is not supported by agent Old status [0]
FYI: We tried this with and without the leading period on the OIDs, it was the same output either way. We also tried several of the built-in template items (ifDescr, for example) with our community string and it has the same result.
What is the deal here? I can't seem to make SNMP work.
This is Solaris 10, Zabbix 1.8.1, running Oracle 11g on the backend.
The snmpwalk works 100% of the time from the command line, so that's not our issue here. The only hint we have is the doubled-up port.
Here's the ldd output from our Zabbix Server binary:
ldd /usr/local/sbin/zabbix_server
libcurl.so.4 => /usr/lib/libcurl.so.4
libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7
libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7
libsocket.so.1 => /lib/libsocket.so.1
libnsl.so.1 => /lib/libnsl.so.1
libdl.so.1 => /lib/libdl.so.1
libz.so.1 => /usr/lib/libz.so.1
libnetsnmp.so.5 => /usr/lib/libnetsnmp.so.5
libgen.so.1 => /lib/libgen.so.1
libelf.so.1 => /lib/libelf.so.1
libclntsh.so.10.1 => /opt/oracle/product/10.2.0.1/lib32/libclntsh.so.10.1
libnnz10.so => /opt/oracle/product/10.2.0.1/lib32/libnnz10.so
libkvm.so.1 => /usr/lib/libkvm.so.1
libm.so.2 => /lib/libm.so.2
libkstat.so.1 => /lib/libkstat.so.1
libresolv.so.2 => /lib/libresolv.so.2
libiconv.so.2 => /usr/lib/libiconv.so.2
libc.so.1 => /lib/libc.so.1
libssl.so.0.9.7 => /usr/sfw/lib/libssl.so.0.9.7
libcrypto.so.0.9.7 => /usr/sfw/lib/libcrypto.so.0.9.7
libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libscf.so.1 => /lib/libscf.so.1
libpkcs11.so.1 => /usr/lib/libpkcs11.so.1
libsched.so.1 => /usr/lib/libsched.so.1
libaio.so.1 => /lib/libaio.so.1
librt.so.1 => /lib/librt.so.1
libm.so.1 => /lib/libm.so.1
libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1
libdoor.so.1 => /lib/libdoor.so.1
libuutil.so.1 => /lib/libuutil.so.1
libcryptoutil.so.1 => /usr/lib/libcryptoutil.so.1
/platform/SUNW,Sun-Fire-T1000/lib/libc_psr.so.1
libssl_extra.so.0.9.7 => /usr/sfw/lib/libssl_extra.so.0.9.7
libcrypto_extra.so.0.9.7 => /usr/sfw/lib/libcrypto_extra.so.0.9.7
/platform/SUNW,Sun-Fire-T1000/lib/libmd_psr.so.1