Überwachen ob ein VM lebt.

Passt mein aktueller Plan, läuft die zweite DNS-VM halt dauerhaft auf einem Failover-Host. Würde mir auch am besten in den Streifen passen. DHCP ist dort selbstverständlich deaktiviert.
Oder man löst vielleicht besser das eigentliche Problem? Ich nutze auch Pi-hole, und bei mir ist das noch nie "abgestürzt". Und falls es tatsächlich einmal hängen oder nicht mehr erreichbar sein sollte, merke ich das ja ohnehin recht schnell, weil dann die DNS-Auflösung auf meinen Geräten nicht mehr funktioniert. ;)

Ernsthaft: Solche sehr spezifischen Überwachungsskripte als Workaround für etwas, das eigentlich gar nicht passieren sollte, erinnern mich ein wenig an die Zeiten, als man Windows-Server jedes Wochenende neu gestartet hat, damit sie die nächste Woche möglichst zuverlässig durchhalten. :p

Anders gesagt: Wenn du deinen Pi-hole überwachen musst, weil er regelmäßig oder potenziell unzuverlässig läuft, dann gibt es vermutlich ein zugrunde liegendes Problem mit dieser Installation. Die Zeit und Energie, die du in eine Überwachungslösung investierst, die genau diesen einen Spezialfall abdeckt, könnte man möglicherweise besser darin investieren, die eigentliche Ursache zu finden.

Zumal du das Problem ohnehin bemerkst, weil dein DNS nicht mehr funktioniert, und es sich um einen Fehlerzustand handelt, der eigentlich gar nicht auftreten sollte.

Nur so meine Gedanken dazu. ;)

(Ich gehe hier davon aus, dass es sich um ein Homelab und nicht um ein Unternehmensnetzwerk mit tausenden Clients handelt, in dem hohe Verfügbarkeit, umfassendes Monitoring und Redundanz tatsächlich geschäftskritisch sind. In so einem Umfeld würde man dann aber eher auf eine ganzheitliche Monitoring-Lösung und entsprechende Redundanz setzen, statt auf punktuelle Skripte, die um einzelne Probleme herumarbeiten sollen, die idealerweise gar nicht erst auftreten.)
 
Last edited:
Ah, da liegt der Knackpunkt: das "in einem Rutsch" wird keine nahtlose Lösung. Die meisten Resolver fragen stur den ersten Nameserver und schwenken erst nach einem Timeout auf den zweiten, bei glibc sind das per Default rund 5 Sekunden pro Versuch. Mit options timeout:1 attempts:2 in der resolv.conf drückst du das deutlich runter. Der Wechsel wird aber meist nicht registriert, der nächste Lookup klopft wieder zuerst beim primären an. Windows kocht da eh sein eigenes Süppchen mit eigener Reihenfolge und Timeouts.

Heißt unterm Strich: solange der erste hart aus ist, hängt jede Abfrage erst, bis der Client umschwenkt. Das wird nicht verzögerungsfrei, sondern merklich langsamer. Für deinen Test einfach mal den primären hart abklemmen und mit dig gegen einen frischen Client die Zeit bis zur Antwort messen, dann siehst du deinen realen Wert.