Hoe je Home Assistant herstelt wanneer de hoofdservice start, maar een afhankelijkheid faalt

Wanneer Home Assistant start maar een afhankelijkheid uitvalt, laat je de hoofdservice lang genoeg draaien om de eerste niet-beschikbare afhankelijkheid te identificeren, in plaats van de installatie opnieuw op te bouwen.

Een gezond proces kan nog steeds een onvolledig systeem opleveren: MQTT-entiteiten zijn mogelijk niet beschikbaar, een externe database kan de geschiedenis blokkeren, een ontbrekende mount kan back-ups verstoren of DNS kan voorkomen dat cloud- en lokale eindpunten worden gevonden. Leg de eerste fout vast, test het genoemde eindpunt vanuit de Home Assistant-runtime en herstel services vanuit de afhankelijkheid naar buiten toe.

Identificeer de eerste fout in een afhankelijkheid

Leg de eerste fout na het opstarten voor de getroffen integratie of service vast, inclusief de naam van de afhankelijkheid, het eindpunt, de uitzonderingsklasse, het herhalingsinterval en het tijdstip. Latere waarschuwingen beschrijven vaak het gevolg — niet-beschikbare entiteiten of een mislukte configuratie — in plaats van de eerste verbindings-, authenticatie-, mount- of schemaveerfout.

Een eenvoudig MQTT-geval laat het verschil zien tussen een integratie configureren en daadwerkelijk een beschikbare broker hebben. Het opgeloste onderscheid tussen brokerconfiguratie en brokerbeschikbaarheid is nuttig, omdat het voorkomt dat je herhaaldelijk wijzigingen aan de client aanbrengt terwijl de vereiste service niet bestaat of niet draait.

Als één naam van een afhankelijkheid vóór alle secundaire fouten verschijnt, maak daar dan het hersteldoel van. Als meerdere onafhankelijke afhankelijkheden tegelijk uitvallen, test dan eerst gedeelde DNS, netwerkverbindingen, opslag of referenties in plaats van elke integratie afzonderlijk te repareren.

Test bereikbaarheid, authenticatie en gereedheid in die volgorde

Los vanuit dezelfde container-, VM- of hostnaamruimte die Home Assistant gebruikt de hostnaam van de afhankelijkheid op, open de vereiste poort, authenticeer met de geconfigureerde identiteit en voer de kleinst beschikbare alleen-lezen-gereedheidscontrole uit. Bereikbaarheid vanaf de host alleen bewijst niet dat de applicatienaamruimte of referenties werken.

De opstartvolgorde van containers staat niet gelijk aan gereedheid van de applicatie; een afhankelijkheid met gezondheidscontrole kan voorkomen dat clients verbinding proberen te maken met een nog niet gereedstaande database of broker. Het onderscheid in opstartvolgorde versus gereedheid ondersteunt het toevoegen van een echte gezondheidscontrole, maar pas nadat de foutconditie is begrepen.

Als het oplossen van de naam mislukt, herstel dan DNS of de servicenaam. Als de poort niet bereikbaar is, herstel dan het proces van de afhankelijkheid of de netwerkroute. Als authenticatie mislukt, vergelijk dan de geconfigureerde bron van de referentie zonder de waarde ervan af te drukken. Als de gereedheidscontrole mislukt nadat de verbinding tot stand is gebracht, inspecteer dan de eigen logs en opslagstatus van de afhankelijkheid.

Herstel de afhankelijkheid met de minst ingrijpende wijziging

Corrigeer alleen de bevestigde fout: herstel de ontbrekende mount, start de broker, repareer de databaseservice, vernieuw de referentie naar de credentials of corrigeer de netwerkalias. Herstart eerst de afhankelijkheid en wacht tot de gereedheidscontrole slaagt; herstart Home Assistant slechts één keer wanneer de client niet automatisch opnieuw verbinding maakt.

Wanneer workers of integraties offline blijven nadat de kernservice is gestart, gebruik dan het probleemoplossingspad voor gereedheid van workers om een vertraagde opstart te onderscheiden van een blijvende afhankelijkheidsgrens.

Rol terug als de afhankelijkheid niet naar de vorige gezonde toestand kan terugkeren of als het herstel het verwijderen van een schema, het opnieuw aanmaken van een database of het blootleggen van credentials vereist. Herstel de laatst bekende configuratie en bewaar de logs van beide kanten voordat je een ingrijpender herstel probeert.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Reproduceer de oorspronkelijke functie en bepaal het stopmoment

Test de exacte functie die is uitgevallen opnieuw: publiceer en ontvang één wegwerpwaarde via MQTT, laad een recent geschiedenisbereik, maak een testback-up naar het beoogde doel of voer één getroffen automatisering uit. Herhaal dit na een gecontroleerde herstart van de afhankelijkheid om opnieuw verbinden te bevestigen, niet alleen onmiddellijke beschikbaarheid.

Er is pas sprake van geslaagd herstel als de gezondheidscontrole van de afhankelijkheid, de integratiestatus van Home Assistant en de functie zoals de gebruiker die ervaart met elkaar overeenkomen. Een draaiende container met niet-beschikbare entiteiten is geen herstel; een groen dashboard terwijl schrijfbewerkingen mislukken evenmin.

Stop wanneer de oorspronkelijke functie twee keer slaagt en er geen nieuwe fouten in afhankelijkheden verschijnen. Escaleer met de eerste uitzondering, de klasse van het eindpunt, het resultaat van de gereedheidscontrole, de versie van de afhankelijkheid en de herstelstappen wanneer de service bereikbaar is, maar protocol- of schemavergelijking nog steeds mislukt.

Leg het herstelde opstartcontract vast

Documenteer welk onderdeel eigenaar is van de afhankelijkheid, het gereedheidssignaal, het retrygedrag, de bron van de credentials, de netwerknaam, het opslagpad en de herstelvolgorde. De volgende operator moet het starten van een proces kunnen onderscheiden van een bruikbare service, zonder het incident opnieuw te hoeven onderzoeken.

Voer tijdens een gepland onderhoudsvenster één geplande herstart van de afhankelijkheid uit en bevestig dat Home Assistant binnen de vastgelegde grens opnieuw verbinding maakt. Als nog steeds handmatige interventie nodig is, vermeld die beperking dan in plaats van de afhankelijkheid als volledig veerkrachtig te markeren.

Sluit het incident pas nadat monitoring zowel een fout in de afhankelijkheid als herstel van de functie kan detecteren. Als monitoring alleen ziet dat het hoofdproces draait, blijft dezelfde blinde vlek bestaan die de onvolledige opstarttoestand heeft veroorzaakt.