XXLRay
20.05.10, 13:00
Ich habe einen Server auf dem sich der snmpd automatisch beendet.
cat /etc/issue.net:
Welcome to openSUSE 11.0 (i586) - Kernel %r (%t).
uname -r:
2.6.25.5-1.1-default
Ich brauche SNMP um eine Remote-Beobachtung mit Cacti zu realisieren.
Mit anderen Systemen im gleichen Netzwerk auf RedHat Enterprise LINUX 4 und 5 funktioniert das wunderbar. Ein anderes OS kommt für den Server nicht in Frage, da OpenSude für bestimmte Programmversionen, die wir aus Lizenzgründen benutzen müssen, benötigt wird.
Das Problem ist, dass der SNMP-Daemon ohne mein Zutun beendet.
SNMP sollte so konfiguriert sein, dass es bei jedem reboot von selbst neu gestartet wird:
chkconfig --list snmpd
snmpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Ich überwache den snmpd mit Nagios. Das hat ergeben, dass der daemon in unregelmäßigen Abständen beendet. Er lässt sich auch ohne Probleme neu starten.
/etc/init.s/snmpd start
cat /var/log/net-snmp
netsnmp_assert !"registration != duplicate" failed agent_registry.c:535 netsnmp_subtree_load()
netsnmp_assert !"registration != duplicate" failed agent_registry.c:535 netsnmp_subtree_load()
netsnmp_assert !"registration != duplicate" failed agent_registry.c:535 netsnmp_subtree_load()
duplicate table data attempted to be entered. row exists
duplicate table data attempted to be entered. row exists
duplicate table data attempted to be entered. row exists
NET-SNMP version 5.4.1
Danach läuft er für mehrere Stunden durch.
Nach einem Login steht in den Logs:
Connection from UDP: [134.169.117.10]:39906
Connection from UDP: [AAA.BBB.CCC.DDD]:39906
Connection from UDP: [AAA.BBB.CCC.DDD]:39906
Connection from UDP: [AAA.BBB.CCC.DDD]:39906
Connection from UDP: [AAA.BBB.CCC.DDD]:39906
Connection from UDP: [AAA.BBB.CCC.DDD]:39906
Connection from UDP: [AAA.BBB.CCC.DDD]:39906
Connection from UDP: [AAA.BBB.CCC.DDD]:39906
Connection from UDP: [AAA.BBB.CCC.DDD]:39906
Connection from UDP: [AAA.BBB.CCC.DDD]:39906
netsnmp_assert !"registration != duplicate" failed agent_registry.c:535 netsnmp_subtree_load()
netsnmp_assert !"registration != duplicate" failed agent_registry.c:535 netsnmp_subtree_load()
netsnmp_assert !"registration != duplicate" failed agent_registry.c:535 netsnmp_subtree_load()
duplicate table data attempted to be entered. row exists
duplicate table data attempted to be entered. row exists
duplicate table data attempted to be entered. row exists
NET-SNMP version 5.4.1
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Mehr nicht... Die "getarnte" IP stammt vom Cacti-Remote-Host.
Ich hab mal versucht SNMP mit Debug-Informationen zu starten:
snmpd -f -Le -Dsnmpd/select -Dsnmp_agent -Dtrap -Dagentx/master
registered debug token snmpd/select, 1
registered debug token snmp_agent, 1
registered debug token trap, 1
registered debug token agentx/master, 1
netsnmp_assert !"registration != duplicate" failed agent_registry.c:535 netsnmp_subtree_load()
netsnmp_assert !"registration != duplicate" failed agent_registry.c:535 netsnmp_subtree_load()
netsnmp_assert !"registration != duplicate" failed agent_registry.c:535 netsnmp_subtree_load()
duplicate table data attempted to be entered. row exists
duplicate table data attempted to be entered. row exists
duplicate table data attempted to be entered. row exists
snmp_agent: final port spec: ""
snmp_agent: installing master agent on port
snmp_agent: init_master_agent; "" registered as an agent NSAP
trap: send_trap 0 0 NET-SNMP-MIB::netSnmpAgentOIDs.10
NET-SNMP version 5.4.1
...
Das hat mich aber irgendwie auch nicht weitergebracht.
Ein Workaround wäre sicherlich einen Cronjob zu schreiben, der regelmäßig prüft, ob der snmpd läuft und in anderenfalls neu startet. Das möchte ich aber vermeiden solange es eine saubere Lösung gibt.
Hat jemand eine Idee, warum der snmpd nicht durchläuft und wie ich das beheben kann? Wenn ihr weitere Informationen benötigt, fragt einfach nach.
cat /etc/issue.net:
Welcome to openSUSE 11.0 (i586) - Kernel %r (%t).
uname -r:
2.6.25.5-1.1-default
Ich brauche SNMP um eine Remote-Beobachtung mit Cacti zu realisieren.
Mit anderen Systemen im gleichen Netzwerk auf RedHat Enterprise LINUX 4 und 5 funktioniert das wunderbar. Ein anderes OS kommt für den Server nicht in Frage, da OpenSude für bestimmte Programmversionen, die wir aus Lizenzgründen benutzen müssen, benötigt wird.
Das Problem ist, dass der SNMP-Daemon ohne mein Zutun beendet.
SNMP sollte so konfiguriert sein, dass es bei jedem reboot von selbst neu gestartet wird:
chkconfig --list snmpd
snmpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Ich überwache den snmpd mit Nagios. Das hat ergeben, dass der daemon in unregelmäßigen Abständen beendet. Er lässt sich auch ohne Probleme neu starten.
/etc/init.s/snmpd start
cat /var/log/net-snmp
netsnmp_assert !"registration != duplicate" failed agent_registry.c:535 netsnmp_subtree_load()
netsnmp_assert !"registration != duplicate" failed agent_registry.c:535 netsnmp_subtree_load()
netsnmp_assert !"registration != duplicate" failed agent_registry.c:535 netsnmp_subtree_load()
duplicate table data attempted to be entered. row exists
duplicate table data attempted to be entered. row exists
duplicate table data attempted to be entered. row exists
NET-SNMP version 5.4.1
Danach läuft er für mehrere Stunden durch.
Nach einem Login steht in den Logs:
Connection from UDP: [134.169.117.10]:39906
Connection from UDP: [AAA.BBB.CCC.DDD]:39906
Connection from UDP: [AAA.BBB.CCC.DDD]:39906
Connection from UDP: [AAA.BBB.CCC.DDD]:39906
Connection from UDP: [AAA.BBB.CCC.DDD]:39906
Connection from UDP: [AAA.BBB.CCC.DDD]:39906
Connection from UDP: [AAA.BBB.CCC.DDD]:39906
Connection from UDP: [AAA.BBB.CCC.DDD]:39906
Connection from UDP: [AAA.BBB.CCC.DDD]:39906
Connection from UDP: [AAA.BBB.CCC.DDD]:39906
netsnmp_assert !"registration != duplicate" failed agent_registry.c:535 netsnmp_subtree_load()
netsnmp_assert !"registration != duplicate" failed agent_registry.c:535 netsnmp_subtree_load()
netsnmp_assert !"registration != duplicate" failed agent_registry.c:535 netsnmp_subtree_load()
duplicate table data attempted to be entered. row exists
duplicate table data attempted to be entered. row exists
duplicate table data attempted to be entered. row exists
NET-SNMP version 5.4.1
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Connection from UDP: [AAA.BBB.CCC.DDD]:39979
Mehr nicht... Die "getarnte" IP stammt vom Cacti-Remote-Host.
Ich hab mal versucht SNMP mit Debug-Informationen zu starten:
snmpd -f -Le -Dsnmpd/select -Dsnmp_agent -Dtrap -Dagentx/master
registered debug token snmpd/select, 1
registered debug token snmp_agent, 1
registered debug token trap, 1
registered debug token agentx/master, 1
netsnmp_assert !"registration != duplicate" failed agent_registry.c:535 netsnmp_subtree_load()
netsnmp_assert !"registration != duplicate" failed agent_registry.c:535 netsnmp_subtree_load()
netsnmp_assert !"registration != duplicate" failed agent_registry.c:535 netsnmp_subtree_load()
duplicate table data attempted to be entered. row exists
duplicate table data attempted to be entered. row exists
duplicate table data attempted to be entered. row exists
snmp_agent: final port spec: ""
snmp_agent: installing master agent on port
snmp_agent: init_master_agent; "" registered as an agent NSAP
trap: send_trap 0 0 NET-SNMP-MIB::netSnmpAgentOIDs.10
NET-SNMP version 5.4.1
...
Das hat mich aber irgendwie auch nicht weitergebracht.
Ein Workaround wäre sicherlich einen Cronjob zu schreiben, der regelmäßig prüft, ob der snmpd läuft und in anderenfalls neu startet. Das möchte ich aber vermeiden solange es eine saubere Lösung gibt.
Hat jemand eine Idee, warum der snmpd nicht durchläuft und wie ich das beheben kann? Wenn ihr weitere Informationen benötigt, fragt einfach nach.