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.
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.
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?
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.
)
