systemctl reset-failed zet de status van een mislukt eenheid en de herstart teller terug naar nul. De opdracht bereidt een nieuwe controle voor, maar repareert de service niet.
Wanneer een systemd eenheid naar de status failed gaat, is de verleiding groot om onmiddellijk systemctl reset-failed uit te voeren. Op een VM, een werkstation of een server kan deze opdracht de zichtbare status verwijderen zonder de oorzaak van de stopzetting aan te raken.
De diagnose begint met de status van de service en zijn logboek. Je kunt dan de specifieke eenheid opnieuw instellen, het resultaat controleren en vervolgens proberen een aparte start uit te voeren als de fout begrijpelijk is.
Lees de service voordat je zijn status reset
Een eenheid die gemarkeerd is als failed duidt de status aan die door systemd wordt gevolgd. Het biedt op zichzelf echter niet de reden voor de crash. Begin met de status en het logboek van de daadwerkelijk betrokken eenheid:
systemctl status mijn-service.service
journalctl -u mijn-service.serviceDe link journalctl maakt het mogelijk om de boodschap van de service in het logboek terug te vinden. Lees deze voordat je de status failed verwijdert, vooral als de eenheid in een lus opnieuw opstart.
Om de huidige status, de substatus, het uitvoeringsresultaat en de herstart teller te scheiden, vraag ook de eigenschappen van de eenheid op:
systemctl show mijn-service.service -p ActiveState -p SubState -p Result -p NRestartsDeze vier waarden beantwoorden verschillende vragen:
ActiveStategeeft de algemene status aan die door systemd wordt gevolgd.SubStatespecificeert de substatus van de eenheid.Resultgeeft het resultaat aan van de uitvoering die tot de mislukking leidde.NRestartsgeeft het aantal geregistreerde herstarts aan.
De opdracht reset-failed verwijdert de status, niet de fout
Na het lezen, richt je je alleen op de betrokken eenheid:
sudo systemctl reset-failed mijn-service.servicesystemctl reset-failed <eentheid> reset de failed status van de eenheid en de herstart teller die aan de startlimiet is gekoppeld. De opdracht herstart de eenheid niet.
Het wijzigt noch ExecStart, noch de rechten, noch de afhankelijkheden, noch de binaire die door de eenheid wordt gebruikt. Het verwijdert ook het logboek niet. De man-pagina van systemctl beschrijft dit gedrag en de andere beschikbare subopdrachten.
De verdwijning van failed kan dus een valse indruk van reparatie geven. De service kan nog steeds een ongeldige configuratie, een ontbrekende afhankelijkheid of een ExecStart opdracht die faalt bevatten.
Controleer het resultaat voordat je een nieuwe opstart uitvoert
Herlees de eigenschappen na de reset. De controle richt zich op de status van de eenheid en de teller, niet op een uitvoer van de opdracht om te kopiëren:
systemctl show mijn-service.service -p ActiveState -p SubState -p Result -p NRestartsAls de oorzaak is begrepen en gecorrigeerd, wordt de opstart een aparte actie:
sudo systemctl start mijn-service.service
systemctl status mijn-service.service
journalctl -u mijn-service.serviceDe status en het logboek maken het mogelijk om de status te constateren die is verkregen na deze opstart. Als de eenheid onmiddellijk opnieuw mislukt, stop dan met de pogingen en corrigeer de oorzaak die in Result of in het logboek is aangetroffen.
Herlaad de eenheidsbestanden met sudo systemctl daemon-reload na het wijzigen van een eenheidsbestand. Deze stap volgt niet automatisch op reset-failed. De map die gewijd is aan systemd herlaadbeurten behandelt dit geval apart.
Voor een service die door een timer is gestart, legt de werking van systemd-timers de relatie uit tussen de service-eenheid en zijn trigger. De teruggezette status corrigeert noch het programma, noch de configuratie, noch de afhankelijkheid die de mislukking veroorzaakt.