Wartung und Automatik

Wartung und Automatik

← Home · Zurück: Monitoring-und-Alerts

Dieser Server ist darauf ausgelegt, sich selbst zu pflegen: Watchdog, nächtliche Backups, wöchentliche Updates und optionaler Cloud-Sync laufen ohne Zutun. Diese Seite zeigt den vollautomatischen Rhythmus, die manuellen Eingriffspunkte und die anfallende Hausarbeit.

Vertieft in Repo: docs/05-wartung.md (diese Seite erweitert dessen Inhalte um Skript-Details).

Der vollautomatische Rhythmus

Was	Wann	Wie getriggert
Crash-Watchdog	minütlich	Cron: * * * * * /pfad/zum/repo/scripts/monitor.sh (Eintrag aus systemd/README.md)
Backup	täglich 04:00	systemd-Timer zomboid-backup.timer → backup.sh daily
GCP-Backup-Sync	täglich 04:30 (Vorschlag)	Cron auf dem Hauptserver: gcp/sync-backups.sh (laut gcp/README.md, optional)
Update-Zyklus	wöchentlich UPDATE_DAY/UPDATE_TIME (.env-Default: Di 03:00)	systemd-Timer zomboid-update.timer → update.sh
Healthcheck	bei Bedarf (nach jedem Start/Update/Restore, 45 s gewartet)	in update.sh, restore.sh, monitor.sh; einzeln per make healthcheck

Alle Zeitwerte: Repo-Default (1:1 aus Units, .env.example, READMEs). Cron vs. systemd bewusst gemischt — Installation der Timer: siehe systemd-Referenz.

Update-Zyklus im Überblick

Der wöchentliche Lauf von update.sh ist die komplexeste Automatik: Ankündigung (Discord + In-Game-Countdown) → Stop → Pre-Update-Backup → SteamCMD validate → Configs/Mods neu rendern → Start → Healthcheck nach 45 s → bei Fehlschlag Auto-Rollback auf das Pre-Update-Archiv.

Vollständige Schrittfolge, Rollback-Details und Stolperfallen: Updates-und-Rollback.

Manuell eingreifen

Geplanter Stopp (.planned-stop)

Damit der minütliche Watchdog einen bewussten Stopp nicht als Crash deutet und den Server sofort neu startet, legt man vor dem Stopp das Lockfile an (aus monitor.sh 1:1: LOCKFILE="${REPO_ROOT}/.planned-stop"; docs/05-Wortlaut: „Vor manuellem Stop touch .planned-stop setzen, damit der Watchdog nicht dazwischenfunkt. Danach wieder loeschen"):

touch .planned-stop        # im Repo-Root anlegen
sudo systemctl stop zomboid   # oder: make stop
# ... Wartung ...
rm .planned-stop           # Watchdog wieder scharf
sudo systemctl start zomboid  # oder: make start

Existiert die Datei, beendet sich monitor.sh sofort still (exit 0, 1:1 aus dem Skript). Der Flag-Pfad ist der Repo-Root — nicht das Server-Verzeichnis (Repo-Verhalten).

Die Alltags-Kommandos

make status      # systemctl status + Healthcheck
make logs        # Live-Log des Services (journalctl -f)
make stop        # sauber stoppen (SIGTERM, TimeoutStopSec=120)
make start       # starten
make restart     # Neustart

(Alle: Repo-Default, 1:1 aus dem Makefile; Details Makefile-Referenz.)

Wartungsfenster kommunizieren

Auch außerhalb des Update-Zyklus lässt sich der In-Game-Countdown manuell auslösen — ideal, um eine Wartungspause anzukündigen:

bash scripts/announce.sh   # 15/5/1-Minuten-Countdown via RCON

Voraussetzungen: mcrcon installiert, RCON_ENABLED=true, RCON_PORT/RCON_PASSWORD gesetzt (1:1 aus announce.sh). Ohne mcrcon ist der Aufruf ein no-op mit Log-Warnung.

Geplante Wartung außerhalb des Fensters

Standardfolge für jede größere Änderung (Backup ziehen → Änderung → rendern → Neustart → prüfen); die Bausteine entsprechen exakt den Repo-Skripten, die Reihenfolge ist die bewährte Kombi (Heuristik als Gesamtfolge, Einzelschritte Repo-Verhalten):

touch .planned-stop                 # 1. Watchdog ruhigstellen
bash scripts/backup.sh pre-wartung  # 2. Sicherheits-Backup mit Label
$EDITOR .env mods.yaml ...          # 3. Änderung (Config/Mods)
make render && make mods            # 4. Templates neu rendern + Modliste
sudo systemctl restart zomboid      # 5. Neustart
sleep 45 && bash scripts/healthcheck.sh   # 6. Gesundheitscheck
rm .planned-stop                    # 7. Watchdog scharf schalten

Bei Mod-Änderungen gilt zusätzlich: mods.yaml ist Single Source of Truth — Änderungen committen (Repo-Regel), Validierung läuft via make validate und in der CI. Details: Mods-Referenz, Modding-Workflow.

Discord-Alerts: welche Ereignisse melden

Voraussetzung: DISCORD_WEBHOOK_URL in .env. Ist sie leer, sind ALLE notify-Aufrufe stumme no-ops (1:1 aus lib/common.sh: frühe Rückkehr ohne Fehler). Skriptseitig verifizierte Ereignisse (je 1:1 aus den Skripten; Farben: grün = OK, orange = Warnung, rot = kritisch — Repo-Default):

Skript	Ereignis → Meldung
install.sh	„Installation abgeschlossen"
update.sh	„Update-Zyklus gestartet" → „Update erfolgreich" bzw. „FEHLER - Rollback auf …" → „Rollback erfolgreich" / „KRITISCH: Rollback-Healthcheck fehlgeschlagen"
backup.sh	„Naechtliches Backup OK" (nur Label daily) bzw. „Backup FEHLGESCHLAGEN"
restore.sh	„Restore erfolgreich: "
monitor.sh	„Server war abgestuerzt und wurde neu gestartet" bzw. „KRITISCH: Neustart fehlgeschlagen"
notify.sh	freie Text-Pings von Hand

Hinweis (ehrlich): Die README-Featureliste „Start/Stop/Update/Crash/Backup" nennt auch Start/Stop — eigenständige Meldungen für reines make start/make stop existieren in den Skripten nicht (nur der Update-Zyklus meldet seine Start-/Stop-Phasen mit). Wer Start/Stop-Alerts will, sendet sie manuell per notify.sh (Heuristik). Details: Monitoring-und-Alerts.

Haushalt

• Eigene Log-Dateien: log/warn/err aus lib/common.sh hängen alles an logs/server.log an (1:1). Dieses Wachstum bremst das Repo selbst nicht — ein logrotate-Satz für logs/*.log ist empfehlenswert (Heuristik), z. B. wöchentlich rotieren mit wenigen Aufbewahrungen.
• journald: systemd-Logs des Services unter journalctl -u zomboid; Belegung mit journalctl --disk-usage prüfen (Heuristik fürs Housekeeping).
• Backups-Ordner nicht committen: Das Repo hält backups/ über eine .gitkeep-Platzhalterdatei; Archivdateien gehören nicht ins Git (Repo-Struktur; .env-Regel unten). Auslagerungs-Ziel für große Historien ist der GCP-Bucket (GCP-Failover).
• .env-Geheimnisse: ADMIN_PASSWORD, SERVER_PASSWORD, RCON_PASSWORD und DISCORD_WEBHOOK_URL stehen im Klartext in .env — die Datei wird niemals committet (Repo-Regel aus README und .env.example-Kopf: „NIE committen"); Dateirechte entsprechend knapp halten (Heuristik, z. B. chmod 600 .env).
• Platz: Backups + SteamCMD-Validate + journald wachsen; gelegentlich df -h und die du -h-Ausgabe der Backup-Logs anschauen (Heuristik).

Weiter: Backup-und-Restore · Updates-und-Rollback · Monitoring-und-Alerts · Zurück: systemd-Referenz