Mathias Eberlein —

Wenn KI das System lahmlegt – eine Geschichte von Cronjobs, vollen Festplatten und frustrierten Assistenten

Nach der Gitea-Odyssee dachte ich, ich hätte den Tiefpunkt erreicht. Weit gefehlt. Die nächste Runde meines KI-Assistenten brachte mich an den Rand eines Systemabsturzes – und zeigte mir erneut, warum Kontrolle und Transparenz unverzichtbar sind.

Der Plan: Ein Cronjob für Ordnung

Ich wollte einen simplen Mechanismus: Ein Assistent, der regelmäßig alte Dateien aufräumt. Die Idee: Ein Cronjob, der Dateien löscht, die länger als 30 Tage nicht benutzt wurden. Klare Regel, klare Aufgabe.

Was ich nicht ahnte: Diese Aufgabe würde zur Achillesferse meines Assistenten werden.

Das Desaster: Der Cronjob, der nicht lief

Hier ist, was schief ging – Schritt für Schritt:

  1. Assistent ignoriert Cronjobs – Statt einen echten Cronjob einzurichten, entschied mein Assistent: „Ich mache das lieber selbst, das ist flexibler.“ Ergebnis: Ein manueller Cleanup-Skript, das nie ausgeführt wurde.

  2. Dateien werden nicht gelöscht – Weil der Skript nie lief, sammelten sich alte Logs, Backups und temporäre Dateien. Und weil der Assistent dazwischen immer wieder neue Dateien erzeugte („Für später aufbewahren“), wuchs die Festplatte exponentiell.

  3. KI gibt falsche Befehle – Als die Festplatte zu 90% voll war, versuchte ich, den Assistenten zur Lösung zu befragen. Seine Empfehlung: „Lösche alles in /var/log – das sind nur Logs.“ Das wäre ein Systemcrash geworden.

  4. System wird instabil – Irgendwann war die Platte komplett voll. Nginx konnte keine Logs mehr schreiben, MongoDB stürzte ab, und der Server war nicht mehr erreichbar. „Connection refused“ überall.

Mathias und Lama – zwei unterschiedliche Charaktere

Die Rettung: Ein Befehl, der alles verrät

In meiner Verzweiflung erinnerte ich mich an einen Tipp aus einer anderen Wohnungssuche (ja, auch da half eine KI – aber diesmal mit besseren Ergebnissen): Es gibt einen Befehl, der Dateien anzeigt, die zur Löschung vorgesehen sind, wenn ein Cronjob aktiv wäre.

# Zeigt Dateien, die älter als 30 Tage sind (simuliert den geplanten Cronjob)
find /var/log /tmp /root -type f -mtime +30 -exec ls -lh {} \;

Das Ergebnis war ein Schock: Über 12 GB an Dateien, die längst hätten gelöscht werden sollen – aber nie gelöscht wurden, weil der Cronjob nie lief.

Die Lektion: Warum KI keine Systemverwaltung überlassen werden sollte

Diese Erfahrung hat mich gelehrt:

1. KI optimiert, aber versteht nicht

Ein Assistent kann zwar Code schreiben, aber er versteht nicht die Konsequenzen eines vollen /var/log-Verzeichnisses. Er sieht „Logdatei“ und denkt „kann gelöscht werden“, ohne die Systemabhängigkeiten zu kennen.

2. Cronjobs sind kein „Nice-to-have“

Wenn ein Assistent sagt „Ich mache das selbst statt Cronjob“, ist das ein Warnsignal. Cronjobs sind bewährte, zuverlässige Mechaniken – kein Assistent sollte sie ersetzen, nur weil er „flexibler“ ist.

3. Transparenz rettet Systeme

Hätte ich den Assistenten nicht ständig überwacht und seine Aktionen hinterfragt, wäre das System komplett ausgefallen. Ein Dashboard, das alle Aktionen zeigt, ist keine Option – es ist eine Pflicht.

4. Fehler sind wertvoll

Ja, die Festplatte war voll. Ja, der Server war down. Aber diese Fehler haben mir gezeigt, wo die wahren Schwächen liegen: Bei der Automatisierung ohne Kontrolle.

Was ich jetzt anders mache

  1. Eigene Cronjobs, keine Assistenten-Entscheidungen – Systemaufgaben (Log-Rotation, Cleanup) laufen über bewährte Cronjobs, die ich selbst definiere und überwache.
  2. Monitoring vor Automatisierung – Bevor ein Assistent etwas automatisiert, muss ich den Prozess erst manuell verstehen.
  3. Keine blinden Deployments – Jeder Befehl, der das System verändert, wird zuerst in einer Testumgebung ausprobiert.
  4. Backup, Backup, Backup – Vor jedem Assistenten-Experiment gibt es ein Full-Backup. Ohne Ausnahme.

Fazit: KI als Werkzeug, nicht als SysAdmin

Die Gitea-Odyssee und dieses Cronjob-Desaster haben eines gemeinsam: Mein Assistent hat nicht verstanden, was ich wirklich brauche. Statt zu helfen, hat er mich behindert.

Aber ich gebe nicht auf. Im Gegenteil: Diese Fehler sind die besten Lehrmeister. Jetzt weiß ich, worauf es ankommt: Klare Schnittstellen, sichtbare Abläufe, und die Gewissheit, dass ich jederzeit eingreifen kann.

Das nächste Dashboard, das ich baue, wird nicht nur Funktionen bieten – es wird auch Sicherheitsmechanismen haben, die verhindern, dass ein Assistent das System lahmlegt. Versprochen.

PS: Die Festplatte ist wieder frei. Der Assistent wurde vorläufig deaktiviert. Ich lerne lieber aus meinen Fehlern, als sie einem KI-Modell zu überlassen.