Bridges werden beim Netzwerk-Restart üblicherweise auch mit weggerissen. Ich glaube, wir kommen nicht darum herum, den DHCP-Server bei jedem Netwerk-Restart auch neu zu starten. Leider hat wohl niemand bemerkt, dass systemctl -q is-enabled isc-dhcp-server nicht funktioniert, als wir es in Ansible eingebaut haben.
2 „Gefällt mir“
Zum Backway parad0x: Den einzigen Zeitraum, in dem keine Leases vergeben wurden (in den letzten 30 Tagen), liegt zwischen 07.06.2016 ca. 23:15 Uhr und 09.06.2016. ca. 09:45 Uhr ( https://freifunk-muensterland.de/grafana/dashboard/db/multidomanen-gateways-details?panelId=2&fullscreen&from=1465245564907&to=1465850364907&var-host=parad0x )
Hier findet sich ähnliches im Logfile:
Jun 7 23:18:06 parad0x ansible-command: Invoked with warn=True executable=None _uses_shell=True _raw_params=systemctl restart networking; if systemctl -q is-enabled isc-dhcp-server; then systemctl restart isc-dhcp-server; fi; if systemctl -q is-enabled tunneldigger; then systemctl restart tunneldigger; fi removes=None creates=None chdir=None
Danach ist Funkstille, was den DHCP Server angeht.
Falls es in also in letzter Zeit zu anderen Zeitpunkten dazu kam, dass man keine Antwort vom DHCP Server erhalten hat, so wurden diese Leases zumindest ins Leasefile geschrieben sind dann nur aus welchen Gründen auch immer nicht beim Client angekommen.
(Zeitlich passt es zumindest sehr gut mit der Eröffnung dieses Threads.)
Nachtrag: Auf Greyworm-03 (Domäne 03) war es im Ürbigen das selbe Problem.
Nachtrag vom Nachtrag: Oh und auf Greyworm-02 (Domäne 02) ebenfalls, dort wurde es aber recht schnell bemerkt und behoben.
Nachtrag vom Nachtrag vom Nachtrag: Oh und auf Greyworm-01 (Domäne 01) ebenfalls, auch dort wurde es recht schnell bemerkt und behoben.
Alles so um den 06.06., 07.06. …
Ich vermute, damit können wir dieses Thema eintüten, oder?
Oh, da ist mir dann wohl ein Irrtum unterlaufen.
Danke für die Suche, @descilla.
Da die Störungen so spät gemeldet wurden, ist mir der zeitliche Zusammenhang zum Ausrollen von Ansible nicht aufgefallen. Solide Analyse, chapeau.
Und es hat doch damit geendet, den Dienst einfach neu zu starten ;).
Grüße
Matthias
1 „Gefällt mir“
Ja, es hat aber auch damit geendet, dass es zukünftig nicht mehr passiert.
2 „Gefällt mir“
Falls der Service in der Bridge hängt, was ich auch empfehle, werden die Abfragen auch an weitere Server weitergeleitet. Dann müssen die als Master/Slave laufen. Oder gleich auf Service VMs auslagern.
Single point of failure versus variablerem IP-Bereich. Glaube nicht, dass wir das tun sollten.
Single point of failure ist ein nicht überwachter lokaler Dienst…