SNMP / Cacti Setup Question :)

[rubyjuice]

Followed the Wiki installation instructions on a CentOS 4.5 install. Got everything working, but ran into an odd issue. When using /etc/init.d/snmpd to start the service, I get no output. However, if I start snmpd manually from the command line, it works fine using: 'snmpwalk -c public -v 1 127.0.0.1 .1.3.6.1.4.1.22253.300'. Any ideas on why starting snmpd with /etc/init.d/snmpd would cause it to cease output?

 

[ffeingol]

Did you try ps -ef | egrep snmp and make sure that it's actually starting with the same parameters, user etc. both ways?

I'd also be interested in how it's working for you. We get very inconsistent results via Cacti.

Frank

 

[rubyjuice]

Thanks for the reply Frank. Yes, I have:

Started with init script: (with and without path)
root 18437 1 0 11:26 ? 00:00:00 /usr/sbin/snmpd
root 18598 1 2 11:29 ? 00:00:00 snmpd

Started manually: (and works fine)
root 18540 1 0 11:28 ? 00:00:00 snmpd

What issues are you experiencing with LS and Cacti?

 

[rubyjuice]

Started snmpd manually and via init script. Enabled debug output on both. Noticed a few differences. Lines starting with "Y:" are from the manually started and working snmp daemon.

Y: results: SNMPv2-MIB::snmpSetSerialNo.0 = INTEGER: 0
N: results: SNMPv2-SMI::enterprises.22253.300 = No Such ...

Y: dumpv_send: ObjID: SNMPv2-MIB::snmpSetSerialNo.0
N: dumpv_send: ObjID: SNMPv2-SMI::enterprises.22253.300

Y:
ucd-snmp/pass: pass-running: /usr/bin/php /opt/lsws/add-ons/snmp_monitoring/sample.php -n .1.3.6.1.4.1.22253.300
trace: netsnmp_call_handler(): agent_handler.c, 389:
handler:returned: handler old_api returned 0

N:
ucd-snmp/pass: pass-running: /usr/bin/php /opt/lsws/add-ons/snmp_monitoring/sample.php -n .1.3.6.1.4.1.22253.300
trace: netsnmp_old_api_helper(): old_api.c, 325:
old_api: evil_client: pass

Y:
trace: netsnmp_call_handler(): agent_handler.c, 389:
handler:returned: handler bulk_to_next returned 0
trace: snmp_call_callbacks(): callback.c, 180:

N:
trace: netsnmp_call_handler(): agent_handler.c, 389:
handler:returned: handler bulk_to_next returned 0
-trace: handle_getnext_loop(): snmp_agent.c, 2746:
-results: getnext results, before next pass:
-trace: handle_getnext_loop(): snmp_agent.c, 2749:
-results: trace: sprint_realloc_by_type(): mib.c, 1971:
-output: sprint_by_type, type 5
-SNMPv2-SMI::enterprises.22253.300 = NULL
-trace: netsnmp_add_varbind_to_cache(): snmp_agent.c, 1748:
-snmp_agent: add_vb_to_cache(0x8633360, 1, SNMPv2-SMI::enterprises.22253.300, 0x862f3f8)
-trace: snmp_call_callbacks(): callback.c, 180:
-callback: START calling callbacks for maj=1 min=12
-trace: snmp_call_callbacks(): callback.c, 188:
-callback: calling a callback for maj=1 min=12
-trace: vacm_in_view(): mibII/vacm_vars.c, 744:
-mibII/vacm_vars: vacm_in_view: ver=0, community=public
-trace: netsnmp_udp_getSecName(): snmpUDPDomain.c, 733:
-netsnmp_udp_getSecName: resolve <"public", 0x0100007f>
-trace: netsnmp_udp_getSecName(): snmpUDPDomain.c, 738:
-netsnmp_udp_getSecName: compare <"public", 0x00000000/0x00000000>... SUCCESS
-trace: netsnmp_subtree_find_first(): agent_registry.c, 156:
-subtree: looking for subtree for context: ""
-trace: netsnmp_subtree_find_first(): agent_registry.c, 160:
-subtree: found one for: ""
-trace: vacm_in_view(): mibII/vacm_vars.c, 851:
-mibII/vacm_vars: vacm_in_view: sn=anonymousSecName000, gn=anonymousGroupName000, vn=anonymousView000
-trace: vacm_checkSubtree(): vacm.c, 526:
-vacm:checkSubtree: , included
-trace: snmp_call_callbacks(): callback.c, 200:
-callback: END calling callbacks for maj=1 min=12 (1 called)
-trace: netsnmp_add_varbind_to_cache(): snmp_agent.c, 1822:
-snmp_agent: tp->start SNMPv2-SMI::enterprises.22254, tp->end SNMPv2-MIB::snmpSetSerialNo.0,
-trace: netsnmp_call_handlers(): agent_handler.c, 443:
-handler:calling: main handler bulk_to_next
-trace: netsnmp_call_handler(): agent_handler.c, 381:
-handler:calling: calling handler bulk_to_next for mode GETNEXT
-trace: netsnmp_call_handler(): agent_handler.c, 381:
-handler:calling: calling handler null for mode GETNEXT
-trace: netsnmp_null_handler(): null.c, 37:
-helper:null: Got request
-trace: netsnmp_null_handler(): null.c, 39:
-helper:null: oid:SNMPv2-SMI::enterprises.22253.300
-trace: netsnmp_call_handler(): agent_handler.c, 389:
-handler:returned: handler null returned 0
-trace: netsnmp_call_handler(): agent_handler.c, 389:
-handler:returned: handler bulk_to_next returned 0
-trace: handle_getnext_loop(): snmp_agent.c, 2746:
-results: getnext results, before next pass:
-trace: handle_getnext_loop(): snmp_agent.c, 2749:
-results: trace: sprint_realloc_by_type(): mib.c, 1971:
-output: sprint_by_type, type 5
-SNMPv2-SMI::enterprises.22253.300 = NULL
-trace: netsnmp_add_varbind_to_cache(): snmp_agent.c, 1748:
-snmp_agent: add_vb_to_cache(0x8633360, 1, SNMPv2-SMI::enterprises.22253.300, 0x8596f70)
-trace: snmp_call_callbacks(): callback.c, 180:
-callback: START calling callbacks for maj=1 min=12
-trace: snmp_call_callbacks(): callback.c, 188:
-callback: calling a callback for maj=1 min=12
-trace: vacm_in_view(): mibII/vacm_vars.c, 744:
-mibII/vacm_vars: vacm_in_view: ver=0, community=public
-trace: netsnmp_udp_getSecName(): snmpUDPDomain.c, 733:
-netsnmp_udp_getSecName: resolve <"public", 0x0100007f>
-trace: netsnmp_udp_getSecName(): snmpUDPDomain.c, 738:
-netsnmp_udp_getSecName: compare <"public", 0x00000000/0x00000000>... SUCCESS
-trace: netsnmp_subtree_find_first(): agent_registry.c, 156:
-subtree: looking for subtree for context: ""
-trace: netsnmp_subtree_find_first(): agent_registry.c, 160:
-subtree: found one for: ""
-trace: vacm_in_view(): mibII/vacm_vars.c, 851:
-mibII/vacm_vars: vacm_in_view: sn=anonymousSecName000, gn=anonymousGroupName000, vn=anonymousView000
-trace: vacm_checkSubtree(): vacm.c, 526:
-vacm:checkSubtree: , included
-trace: snmp_call_callbacks(): callback.c, 200:
-callback: END calling callbacks for maj=1 min=12 (1 called)
-trace: netsnmp_add_varbind_to_cache(): snmp_agent.c, 1822:
-snmp_agent: tp->start SNMPv2-MIB::snmpSetSerialNo.0, tp->end SNMPv2-MIB::snmpSetSerialNo.1,
-trace: netsnmp_call_handlers(): agent_handler.c, 443:
-handler:calling: main handler bulk_to_next
-trace: netsnmp_call_handler(): agent_handler.c, 381:
-handler:calling: calling handler bulk_to_next for mode GETNEXT
-trace: netsnmp_call_handler(): agent_handler.c, 381:
-handler:calling: calling handler serialize for mode GETNEXT
-trace: netsnmp_serialize_helper_handler(): serialize.c, 59:
-helper:serialize: Got request
-trace: netsnmp_call_handler(): agent_handler.c, 381:
-handler:calling: calling handler instance for mode GETNEXT
-trace: netsnmp_instance_helper_handler(): instance.c, 543:
-helper:instance: Got request:
-trace: netsnmp_instance_helper_handler(): instance.c, 548:
-helper:instance: oid:SNMPv2-SMI::enterprises.22253.300
-trace: netsnmp_call_handler(): agent_handler.c, 381:
-handler:calling: calling handler long_handler for mode GET
-trace: netsnmp_instance_long_handler(): instance.c, 388:
-netsnmp_instance_long_handler: Got request: 160
-trace: netsnmp_call_handler(): agent_handler.c, 381:
-handler:calling: calling handler snmpSetSerialNo for mode GET
-trace: netsnmp_call_handler(): agent_handler.c, 389:
-handler:returned: handler snmpSetSerialNo returned 0
-trace: netsnmp_call_handler(): agent_handler.c, 389:
-handler:returned: handler long_handler returned 0
-trace: netsnmp_call_handler(): agent_handler.c, 389:
-handler:returned: handler instance returned 0
-trace: netsnmp_call_handler(): agent_handler.c, 389:
-handler:returned: handler serialize returned 0
-trace: netsnmp_call_handler(): agent_handler.c, 389:
-handler:returned: handler bulk_to_next returned 0
trace: snmp_call_callbacks(): callback.c, 180:

 

[ffeingol]

What issues are you experiencing with LS and Cacti?

Well, basically the implementation Because it's a snapshot every 5 minutes instead of a counter you get very weird looking graphs. You could have a huge spike that lasts for 4m 59s and totally miss it.

Frank

 

[rubyjuice]

Ah, right. Yes, that is troublesome. Real-time stats outside of LS would be great.