wir brauchen dringend was, das die DHCP-Server neu startet, wenn z. B. 15 min keine Adresse vergeben wurde. Auf dem Parad0x-Gateway stürzt der irgendwie zweimal wöchentlich ab.
Irgendwie ein Cronjob mit der Pseudosyntax:
grep -i dhcp /var/log/syslog
Zeitstempel - 15 min errechnen und vorderen Teil abschneiden
Ich würde sagen, das sollten wir als Cronjob etablieren und per Ansible auf alle Kisten ausrollen, die DHCP haben. Warum auch immer dieser relativ simple Dienst ständig die Grätsche macht, ist einfach unnötig, dass dann das Netz mehrere Stunden steht.
Wenn ich das wüsste, würde ich mir das ansehen. Es ist einfach so, dass das Ding keine IPs mehr vergibt.
Wer Zeit hat, ist herzlich eingeladen, das beim nächsten mal zu diagnostizieren. Die Zeit hatte ich vorhin einfach nicht, daher habe ich den Service neu gestartet, damit es wieder läuft.
Mal im Ernst.
Ich denke das die Idee von MPW ein guter Plan B ist.
Aber wenn wir das eigentliche Problem eingrenzen und mit etwas Glück beheben könne wäre es viel besser.
Bitte beim nächsten “Crash” den genauen Zeitpunkt (Fehler bemerkt und DHCP neu gestartet) notieren, womit wir dann versuchen den Fehler einzugrenzen.
Ich werde beim nächsten mal einfach rumfragen, wer Zeit hat, das Problem zu diagnostizieren. Falls jemand innerhalb von 3-4 Stunden Zeit hat, können wir ihn einfach kaputt stehen lassen und nicht neustarten.
Ich bezweifle den Erfolg, weil die Netzwerktopologie steht. Die IPV4-Route ist da und IPV6 geht normal. Daher vermute ich ein Problem innerhalb des DHCP-Servers. Eventuell kann man aber genug Daten sammeln, um irgendwo einen Bugreport zu erstellen.
Nein! Einen Dienst andauernd neu zu starten, weil es Probleme damit geht halte ich für die Schlechteste aller möglichen Optionen, gar für dilletantisch.
Außerdem denke ich nicht, dass es an dem Dienst als solches liegt. Entweder wir haben etwas total falsch konfiguriert oder es hängt irgendwie mit dem batman zusammen. Diese Annahme fußt darauf, dass der isc dhcp eigentlich überall eingebaut ist.
Wir müssen das Problem also wohl oder übel debuggen. Wenn das noch etwas dauert, dann ist da so, das kommt halt dabei heraus, wenn niemand bock auf Technik hat.
Kann man dann ein Image der VM erstellen und danach den Server neu starten?
Dann kann man das Image irgendwo anders starten und nach dem Fehler in Ruhe suchen?
(Ich hab ja so gar keine Ahnung! )
Ich halte es schon für wichtig den Server als Plan B dann zumindest einfach (vielleicht auch automatisiert und mit Protokollierung) neu zu starten, um das Netz am laufen zu halten und den Admins nicht über Gebühr zu beanspruchen.
Aber eine schlechte Publicity (z.B. ala „Beim Freifunk kann man gar nicht alles aufrufen! Ich geh lieber ins LTE Netz!“) sollten wir uns besser nicht leisten. Dann lieber den Server jede Nacht neu starten.
Eben nicht.
Es geht ja auch darum die Fehlfunktion abzustellen. Und dazu halt die Frage ob der Prozess abschmiert, nicht mehr antwortet und/oder ob was im Log steht.
Laut Logfile ist das letzte DHCP Lease Jun 6 12:55:02 vergeben wurden. Zeitgleich mit einem systemctl restart networking; if systemctl -q is-enabled isc-dhcp-server; then systemctl restart isc-dhcp-server; fi (über Ansible ausgeführt) stellte der dhcp Server dann seinen Dienst ein.
Folgendes:
root@greyworm-05 ~ # service isc-dhcp-server status
● isc-dhcp-server.service - LSB: DHCP server
Loaded: loaded (/etc/init.d/isc-dhcp-server)
Active: active (running) since Thu 2016-05-12 23:07:51 CEST; 1 months 1 days ago
Process: 1028 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/isc-dhcp-server.service
└─1122 /usr/sbin/dhcpd -q -cf /etc/dhcp/dhcpd.conf -pf /var/run/dhcpd.pid bat0
Legt die Vermutung nahe, dass der dhcp Service zu diesem Zeitpunkt nicht neu gestartet wurde. Ich möchte noch mal dazu anregen, den dhcp service in eine bridge zu hängen anstatt direkt ins batman interface. Da wir uns hierbei auch den restart des DHCP Services beim netzwerk restart sparen würden.
Ob es sich bei dem aktuellen Problem nun um das Problem (also das irgendwie mit den 15 Minuten kein Lease und so) gehandelt hat, weiß ich nicht. Müssen wir beim nächsten “Kandidaten” schauen.
PS: Ich habe zu Testzwecken die Tools dhcpdump und dhcping installiert, diese schmeiße ich gleich auch noch ins Ansible.
…ich werde jetzt mal schauen, warum der o. g. Befehl den dhcp Server nicht neu gestartet hat.
PPS: Achso, ich habe den DHCP-Server dann mal neu gestartet.
Nachtrag:
Manuelles Ausführen des Befehls gibt folgendes auf die Konsole aus:
root@greyworm-05 ~ # systemctl restart networking; if systemctl -q is-enabled isc-dhcp-server; then systemctl restart isc-dhcp-server; fi
Failed to get unit file state for isc-dhcp-server.service: No such file or directory
Aber eigentlich wollen wir ja auch nur wissen, ob der Service läuft, also geht auch folgendes (was dann funktioniert hat):
root@greyworm-05 ~ # systemctl restart networking; if systemctl -q is-active isc-dhcp-server; then systemctl restart isc-dhcp-server; fi
root@greyworm-05 ~ #
Ich passe das mal im Ansible an.
PS: Und genau deshalb halte ich nichts von Scripten, die irgendetwas irgendwann neustarten nur weil irgendetwas irgendwie manchmal sonst nicht funktioniert. Meißt schießt man sich damit selbst ins Knie. Da ist dann noch nicht mal jemand schuld dran, es macht die ganze Kacke nur komplexer und das Verhalten des Systems nicht unbedingt besser nachvollziehbar. Deshalb bin ich weiterhin dafür zu schauen, was kaputt ist und nicht irgendwelche restart Skripte zu bauen.
Interessanter ist, wer was ausgerollt hat. Ich war es nicht. Und wenn das bedeutet, dass die anderen Probleme auch daher kamen, schlampt irgendwer ganz schön mit dem Admintagebuch.
