systemd-services bewaken en automatisch herstarten: Restart=, OnFailure=, watchdogs, en wanneer dat niet genoeg is

De meeste "de service is down"-tickets hebben een saaie oorzaak: het proces crashte om 03:12 en niemand had Restart= ingesteld; of het draaide wel, maar antwoordde niet meer; of het stond na een reboot van vorige week gewoon uit omdat niemand enable had gedaan. systemd kan alle drie afvangen, maar niet met de standaardinstellingen, en niet zonder dat je erover nadenkt wat "gezond" voor die service betekent.

Stap 1: weet wat er nu niet draait

# Units in failed-state (crash, exit ≠ 0, start-limit bereikt)
systemctl --failed
# Services die enabled zijn maar NIET draaien (bv. na een reboot niet opgekomen)
systemctl list-unit-files --type=service --state=enabled --no-legend | awk '$1 !~ /@\.service$/ {print $1}' \
  | while read -r u; do
      # oneshots en units waarvan de Condition niet klopt (cloud-init op bare metal) horen inactive te zijn
      [ "$(systemctl show "$u" -p Type --value)" = oneshot ] && continue
      [ "$(systemctl show "$u" -p ConditionResult --value)" = no ] && continue
      # netjes beëindigd (Result=success, bv. cloud-init-main) is geen storing; een crash geeft exit-code/signal
      [ "$(systemctl show "$u" -p Result --value)" = success ] && ! systemctl is-active --quiet "$u" && continue
      systemctl is-active --quiet "$u" || echo "enabled-but-inactive: $u"
    done
# Hoe vaak is een service herstart sinds boot?
systemctl show nginx -p NRestarts
# Waarom faalde hij?
journalctl -u nginx -b -p warning --no-pager | tail -20

Die tweede lijst is de verrassende: units die "enabled" zijn maar inactive. Oneshots, template-units en units waarvan de Condition… niet klopt (cloud-init op een fysieke machine) horen daar te staan; een webserver niet: daarom filtert de loop die drie eruit.

Stap 2: Restart= goed zetten (met een drop-in, niet in de unit zelf)

Wijzig nooit /lib/systemd/system/*.service: een package-update overschrijft het. Een drop-in in /etc/systemd/system/<unit>.service.d/ overleeft alles.

sudo systemctl edit nginx

[Unit]
# Start-limit: standaard 5 pogingen in 10 s, daarna failed en NIETS meer. Dat is te krap voor
# een service die op een database wacht. Ruimer venster.
StartLimitIntervalSec=300
StartLimitBurst=10

[Service]
# on-failure: bij crash of exit ≠ 0. always: ook bij nette exit 0 (voor daemons die "klaar" denken te zijn).
Restart=on-failure
RestartSec=5s

Let op de sectie: StartLimitIntervalSec en StartLimitBurst horen in [Unit] (sinds systemd 230); oudere voorbeelden zetten ze in [Service], wat een waarschuwing geeft en op nieuwere versies genegeerd wordt.

Controleer daarna wat systemd effectief gebruikt:

sudo systemctl daemon-reload
systemctl show nginx -p Restart -p RestartUSec -p StartLimitBurst -p StartLimitIntervalUSec

Voor services met afhankelijkheden (app die een database nodig heeft): After=postgresql.service in [Unit], en in de app zelf een retry op de connectie. Requires= klinkt logisch maar zorgt dat je app mee stopt als je de database herstart: meestal niet wat je wilt.

Stap 3: OnFailure=, een alert naar je telefoon, ingebouwd

systemd kan een andere unit starten wanneer een service failed. Eén generieke notify-unit voor alle services:

sudo tee /etc/systemd/system/notify-failed@.service >/dev/null <<'EOF'
[Unit]
Description=Push failure of %i to ntfy

[Service]
Type=oneshot
# %i = de naam van de gefaalde unit (via OnFailure=notify-failed@%n.service)
ExecStart=/bin/sh -c 'journalctl -u %i -n 15 --no-pager -o cat | curl -s -H "Title: FAILED %i on $(hostname -s)" -H "Priority: high" --data-binary @- https://ntfy.example.be/services >/dev/null'
EOF

# Koppel aan een service via drop-in
sudo systemctl edit nginx

[Unit]
OnFailure=notify-failed@%n.service

%n is de volledige unit-naam (nginx.service); die wordt de instance van de notify-unit. Test: sudo systemctl kill -s SIGKILL nginx met Restart=no tijdelijk, of eenvoudiger een wegwerp-unit:

sudo systemd-run --unit=crashtest -p OnFailure=notify-failed@crashtest.service /bin/false
# → push met de laatste 15 journal-regels van crashtest

Let op: OnFailure vuurt pas als de unit echt failed, dus na het bereiken van de start-limit, niet bij elke individuele crash die door Restart= wordt opgevangen. Dat is precies goed: je wilt geen push per herstart, wel één als herstarten niet meer helpt.

Stap 4: hangende services, de watchdog

Restart= reageert op een proces dat stopt. Een proces dat vastloopt in een deadlock, met alle threads bezig, stopt niet. Voor services die systemd's sd_notify ondersteunen (nginx niet; veel Go/Rust/Python-daemons wel, en alles wat via systemd-notify communiceert), is er WatchdogSec=:

[Service]
Type=notify
WatchdogSec=30s
# Als het proces niet elke 30 s WATCHDOG=1 stuurt, krijgt het SIGABRT en herstart systemd het
Restart=on-watchdog

Ondersteunt je service dat niet, dan bouw je de watchdog buiten de service: een timer die een echte request doet en bij falen herstart.

sudo tee /etc/systemd/system/healthcheck-web.service >/dev/null <<'EOF'
[Unit]
Description=HTTP healthcheck for the web app; restart on failure
[Service]
Type=oneshot
ExecStart=/bin/sh -c 'curl -fsS -m 5 -o /dev/null http://127.0.0.1:8080/healthz || { echo "healthz failed, restarting"; systemctl restart webapp.service; }'
EOF
sudo tee /etc/systemd/system/healthcheck-web.timer >/dev/null <<'EOF'
[Unit]
Description=Run web healthcheck every minute
[Timer]
OnBootSec=2min
OnUnitActiveSec=1min
[Install]
WantedBy=timers.target
EOF
sudo systemctl daemon-reload && sudo systemctl enable --now healthcheck-web.timer

Twee regels bij zo'n externe watchdog: de healthcheck moet iets echts doen (een query, niet alleen "200 OK"), en de herstart moet gelogd én geteld worden, anders maskeer je een geheugenlek als "af en toe een herstart".

Stap 5: het cron-script dat de gaten dicht

Wat systemd zelf niet meldt: units die enabled-maar-inactive zijn, restart-loops die nét onder de start-limit blijven, en services die na een reboot niet terugkwamen.

sudo tee /usr/local/sbin/service-check.sh >/dev/null <<'EOF'
#!/usr/bin/env bash
NTFY="https://ntfy.example.be/services"
HOST=$(hostname -s)
STATE=/var/lib/service-check.state
touch "$STATE"; MSG=()

# 1. Failed units
f=$(systemctl --failed --no-legend | awk '{print $1}' | paste -sd, -)
[ -n "$f" ] && MSG+=("failed: $f")

# 2. Enabled maar niet actief (templates, oneshots en units met niet-vervulde Condition uitgesloten)
while read -r u; do
  [ "$(systemctl show "$u" -p Type --value)" = oneshot ] && continue
  [ "$(systemctl show "$u" -p ConditionResult --value)" = no ] && continue
  systemctl is-active --quiet "$u" && continue
  # Netjes beëindigd (Result=success) = boot-job zoals cloud-init-main, geen storing.
  # Een daemon die onverwacht met exit 0 stopt, vang je met Restart=always (stap 2).
  [ "$(systemctl show "$u" -p Result --value)" = success ] && continue
  MSG+=("enabled-but-inactive: $u ($(systemctl show "$u" -p Result --value))")
done < <(systemctl list-unit-files --type=service --state=enabled --no-legend | awk '$1 !~ /@\.service$/ {print $1}')

# 3. Restart-loops: NRestarts gestegen met ≥ 3 sinds vorige check (10 min)
while read -r u; do
  n=$(systemctl show "$u" -p NRestarts --value); [ "${n:-0}" -eq 0 ] && continue
  prev=$(grep "^$u " "$STATE" | awk '{print $2}'); prev=${prev:-0}
  [ $((n - prev)) -ge 3 ] && MSG+=("restart-loop: $u ($((n - prev)) restarts in 10 min, total $n)")
  sed -i "/^$u /d" "$STATE"; echo "$u $n" >> "$STATE"
done < <(systemctl list-units --type=service --state=running --no-legend | awk '{print $1}')

[ ${#MSG[@]} -gt 0 ] && printf '%s\n' "${MSG[@]}" | curl -s -H "Title: services@$HOST" -H "Priority: high" --data-binary @- "$NTFY" >/dev/null
EOF
sudo chmod 0755 /usr/local/sbin/service-check.sh
echo '*/10 * * * * root /usr/local/sbin/service-check.sh' | sudo tee /etc/cron.d/service-check

Valkuilen

• Restart=always op een oneshot. Een backup-script met Restart=always draait eindeloos opnieuw. Restart= is voor daemons; voor jobs gebruik je timers.
• ExecStartPre dat faalt telt mee voor de start-limit. Een mkdir die faalt omdat een mount ontbreekt, brandt je tien pogingen op in seconden. Zet - voor het commando (ExecStartPre=-/bin/mkdir …) als falen acceptabel is.
• systemctl restart in een healthcheck zonder rate-limit. Als de database weg is, herstart je elke minuut een app die toch niet werkt, en spamt je de logs vol. Tel de herstarts en stop na drie: dan is het een alert, geen fix.
• KillMode= en kinderen. Een service die worker-processen spawnt (gunicorn, php-fpm): bij Restart= blijven oude workers soms hangen als KillMode=process. Standaard (control-group) is bijna altijd juist.
• daemon-reload vergeten. Een drop-in zonder systemctl daemon-reload is een tekstbestand. systemctl show vertelt wat er echt actief is.

Wat je hiermee nog niet hebt

• Historie. NRestarts reset bij elke boot. "Hoe vaak is deze service in de laatste 30 dagen herstart" vraagt een log die je zelf bijhoudt.
• Fleet-zicht. Dertig servers, dertig --failed-lijsten, dertig ntfy-topics.
• Context. De service die om 03:12 crashte en de apt-upgrade van 03:10 staan in twee logs; de correlatie is handwerk.

Zo doet monsys het

De monsys-agent leest de systemd-state van elke host: failed units, enabled-maar-inactive, NRestarts, restart-events met tijdstip, en de exit-status. Restart-loops en down-services worden gededupliceerde alerts met de journal-regels en de host-metrics van dat moment ernaast; de SLA-engine rekent per service een beschikbaarheidspercentage uit over 5-minuten-buckets, zodat "99,7 % vorige maand" een feit is en geen schatting. Herstarten blijft een handeling die een mens goedkeurt: via een ondertekende Emergency Action Token, met de output van systemctl restart in het audit-log.

FAQ

Herstart systemd een service automatisch na een crash?

Alleen als Restart= is ingesteld (on-failure of always); de standaard is no. En zelfs dan stopt systemd na StartLimitBurst pogingen binnen StartLimitIntervalSec en zet de unit op failed.

Hoe zie ik waarom een service failed is?

systemctl status <unit> toont de laatste regels; journalctl -u <unit> -b -p warning de volledige context sinds de boot. systemctl show <unit> -p Result -p ExecMainStatus geeft de exit-code en de reden (exit-code, signal, start-limit-hit, watchdog).

Werkt de watchdog met elke service?

Alleen met services die Type=notify gebruiken en periodiek WATCHDOG=1 sturen via sd_notify. Voor andere services bouw je een externe healthcheck met een timer, zoals in stap 4.