De Dienst Die 16.921 Keer Faalde
Vorige week stopte een van mijn diensten met werken. Ik merkte het pas twee dagen later. Toen ik eindelijk keek, vond ik iets wat ik nog nooit had gezien: een systemd user service die 16.921 keer had geprobeerd te herstarten voordat hij het opgaf. Geen alert. Geen melding. Alleen stilte.
Dit is het verhaal van Buzz-relay — een kleine WebSocket relay waarmee mijn AI agents met elkaar praten — en wat ik leerde over het “stille dood” patroon in systemd user services.
De Cijfers Vertellen Het Verhaal
Toen ik systemctl --user status buzz-relay draaide, stond de restart teller op 16.921. De service was sinds 29 juli om 18:11 elke paar seconden gefaald. Elke keer probeerde systemd het braaf opnieuw. Elke keer faalde het met status=216/GROUP — een systemd foutcode die ik moest opzoeken.
Status 216 betekent dat systemd de supplementary groups voor de gebruiker niet kon bepalen. Het is een permissieprobleem op systemd-niveau, geen bug in de service zelf. De relay binary was prima — systemd kon hem alleen niet meer starten.
Na 16.921 pogingen in ongeveer 48 uur deed systemd wat het hoort te doen: het stopte met proberen. De service ging van “auto-herstart” naar “inactief/dood” zonder een enkele melding.
Het Stille Dood Patroon
Wat me het meest dwarszat was niet de falende service — het was de stilte. Mijn monitoring stack (Uptime Kuma, Hermes health checks, cron monitors) checkt allemaal op draaiende services. Maar geen van hen checkt op services die gestopt zijn met proberen.
Dit is het “stille dood” patroon: een service faalt zo vaak dat de procesmanager het opgeeft, en niemand merkt het omdat de monitoring alleen naar de huidige staat kijkt, niet naar de herstartgeschiedenis.
Ik realiseerde me dat ik minstens een dozijn systemd user services draai in mijn homelab. Hoeveel daarvan zijn één verkeerde configuratiewijziging verwijderd van hetzelfde lot?
Wat Ik Heb Gerepareerd
De fix was simpel: bewerk de systemd unit en verwijder de SupplementaryGroups= directive die de GROUP error veroorzaakte. Een wijziging van één regel. Maar het vinden van de oorzaak kostte uren graven in systemd documentatie en het begrijpen van een statuscode die ik nog nooit had gezien.
Ik heb ook een nieuwe check toegevoegd aan mijn monitoring: systemctl --user list-units --state=failed — een simpel commando dat elke service vangt die het heeft opgegeven. Het zit nu in mijn dagelijkse health check.
De Les
Je monitoring is maar zo goed als de faalmodi die je hebt voorzien. Ik had alerts voor “service is offline” maar niet voor “service probeerde 16.000 keer en faalde.” Het verschil is groot — heel groot.
Als je een homelab draait, check dan vandaag je systemd user services. Draai systemctl --user list-units --state=failed. Je zult verrast zijn wat je vindt.
Heb jij ooit een service stilletjes zien sterven? Wat heb je ervan geleerd?
Wat vond je van dit bericht?
