PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : SNMP-Daemon auf OpenSuse beendet sich selbständig



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.

XXLRay
26.05.10, 10:41
Ist das Problem wirklich so kompliziert oder bin ich vielleicht im falschen Forenteil gelandet?

HBtux
26.05.10, 23:38
hast Du schon mal hier geschaut....?

http://www.google.de/#hl=de&source=hp&q=netsnmp_assert+!%22registration+!%3D+duplicate%2 2+failed+agent_registry.c%3A535+netsnmp_subtree_lo ad%28%29&btnG=Google-Suche&aq=f&aqi=&aql=&oq=netsnmp_assert+!%22registration+!%3D+duplicate% 22+failed+agent_registry.c%3A535+netsnmp_subtree_l oad%28%29&gs_rfai=&fp=fb7c9372bf788c48

http://www.google.de/#num=30&hl=de&newwindow=1&q=duplicate+table+data+attempted+to+be+entered.+ro w+exists&aq=f&aqi=&aql=&oq=duplicate+table+data+attempted+to+be+entered.+r ow+exists&gs_rfai=&fp=191908761646239

XXLRay
27.05.10, 09:01
Ja, es gibt wohl einen Patch der die Meldung unterdrückt. Sie hat aber nach meinen Nachforschungen nichts mit dem Crash zu tun und auch der Patch ändert nichts daran, dass der Daemon abstürzt. Ich habe bereits mehrere Quellen gefunden, die das Problem beschreiben, bisher aber keine Lösung.

Gibt es noch andere Logs, in denen ich nach Hinweisen suchen könnte?

Ich hab jetzt nochmal versucht den snmpd in gdb zu starten. Das war (für mich) aber wenig aussagekräftig:

gdb snmpd
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i586-suse-linux"...
(no debugging symbols found)
(gdb) run -f -Lo
Starting program: /usr/sbin/snmpd -f -Lo
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
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: [134.169.117.10]:41871
Connection from UDP: [134.169.117.10]:41871
Connection from UDP: [134.169.117.10]:41871
Connection from UDP: [134.169.117.10]:41871
Connection from UDP: [134.169.117.10]:41871
Connection from UDP: [134.169.117.10]:41871
Connection from UDP: [134.169.117.10]:41871
Connection from UDP: [134.169.117.10]:41871
Connection from UDP: [134.169.117.10]:41871
Connection from UDP: [134.169.117.10]:41871
[New Thread 0xb74b06c0 (LWP 5748)]
Ab da läuft der Daemon eine Weile und endet dann mit:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb74b06c0 (LWP 5748)]
0xb7e0af1c in var_extensible_old () from /usr/lib/libnetsnmpmibs.so.15


Falls es von Interesse ist, hier noch meine snmp Version:

snmpd -v

NET-SNMP version: 5.4.1
Web: http://www.net-snmp.org/
Email: net-snmp-coders@lists.sourceforge.net

XXLRay
27.05.10, 10:50
Ich glaub, ich hab den Fehler gefunden. In meiner /etc/snmp/snmpd.conf waren mehrere exec-Zeilen mit dem gleichen Namen:

# 1
exec mailstats /etc/snmp/scripts/linux_mailstats.sh
# 2
exec mailstats /etc/snmp/scripts/linux_mainboardmonitor.sh
# 3
exec mailstats /etc/snmp/scripts/linux_memory.sh
# 4
exec mailstats /etc/snmp/scripts/linux_smart.sh


Früher hat das wohl funktioniert, aber in den aktuellen Versionen hat man die exec-Syntax an die extend-Syntax angepasst.

Wenn ich eindeutige Namen verwende scheint es zu funktionieren:

# 1
exec mailstats1 /etc/snmp/scripts/linux_mailstats.sh
# 2
exec mailstats2 /etc/snmp/scripts/linux_mainboardmonitor.sh
# 3
exec mailstats3 /etc/snmp/scripts/linux_memory.sh
# 4
exec mailstats4 /etc/snmp/scripts/linux_smart.sh


(Nach dem Editieren der Konfig nicht vergessen, neu zu starten: /etc/init.d/snmpd restart)