KeyHelp: Wartungsintervalle verstehen und mit keyhelp run manuell auslösen

KeyHelp erledigt vieles nicht sofort, sondern in festen Abständen im Hintergrund: Konfigurationsdateien schreiben, Speicherplatz zählen, Statistiken bauen, Zertifikate prüfen, Updates einspielen. Wer weiß, wann welcher Job läuft, versteht, warum eine Änderung im Panel erst nach bis zu einer Minute wirkt oder warum die Speicherplatzanzeige hinterherhinkt. Diese Anleitung zeigt, wo die Intervalle stehen, wie sie technisch angestoßen werden und wie Sie einen Job mit keyhelp run oder über „Jetzt starten“ sofort auslösen. Sie richtet sich an Administratoren eines Servers wie in KeyHelp installieren und absichern. Getestet haben wir mit KeyHelp 26.1.1 auf Debian 12.

Voraussetzungen

• Ein KeyHelp-Server mit Administrator-Zugang. Getestet mit KeyHelp 26.1.1 (Build 3698) auf Debian 12.15.
• SSH-Zugang als root für keyhelp run und die Protokolle.

Schritt 1: Die Wartungsintervalle im Panel ansehen

Öffnen Sie als Administrator „Einstellungen“, „Wartungsintervalle“. Die Seite erklärt selbst: „Um von Nutzern ausgelöste Aufgaben zu verarbeiten, müssen verschiedene serverseitige Operationen durchgeführt werden.“ und warnt: „Bitte ändern Sie die Einstellungen nur, wenn Sie sich ihrer Wirkung bewusst sind.“

Im Grundzustand unseres Testservers standen dort diese Werte:

Aufgaben-Name	Name für keyhelp run	Intervall	Zeitfenster
Aufgaben abarbeiten	update	1 Minute	von 00 bis 00 Uhr
Speicherplatz berechnen	diskspace	1 Stunde	von 00 bis 00 Uhr
Control Panel aktualisieren	panel-update	1 Tag	von 03 bis 04 Uhr
Statistik aktualisieren	statistic	1 Stunde	von 00 bis 01 Uhr
Server-Dienste aktualisieren	package-update	2 Tage	von 03 bis 04 Uhr
Aufräumarbeiten durchführen	cleanup	6 Stunden	von 00 bis 00 Uhr
Virenprüfung durchführen	avscan	7 Tage	von 01 bis 02 Uhr
SSL/TLS-Zertifikate warten	ssl-maintenance	1 Tag	von 00 bis 01 Uhr
PHP-Interpreter aktualisieren	php-update	1 Tag	von 05 bis 06 Uhr

Die Zuordnung von Anzeigename zu Kurzname stammt aus der KeyHelp-Datenbank, Tabelle keyhelp.maintenance_intervals. Dort gibt es einen zehnten Eintrag ssh-chroot-update mit der Markierung pro = 1, der im Panel unserer Testinstallation nicht erschien. Die Serverzeit war im Test Etc/UTC, auch das Panel zeigte die Zeiten in UTC. Bei „Server-Dienste aktualisieren“ steht der Hinweis, dass der Job apt update und apt upgrade ausführt, apt dist-upgrade aber nicht: „KeyHelp führt diesen Befehl nicht automatisch aus, da Updates installiert werden können, die zu funktionsbeeinflussenden Änderungen in der auf dem Server verwendeten Software führen könnten.“

Verifizieren: Die Spalte „Letzter Lauf“ zeigt bei „Aufgaben abarbeiten“ eine Uhrzeit, die höchstens eine Minute zurückliegt. Im Test stand bei den nächtlichen Jobs wie „Control Panel aktualisieren“ noch kein Zeitpunkt, sondern nur ein Strich, weil der Server erst am selben Tag installiert war.

Schritt 2: Verstehen, wer die Jobs anstößt

Für die Wartungsintervalle gibt es keinen systemd-Timer und keinen eigenen Cron-Eintrag pro Job. Auf dem Testserver lag in /etc/cron.d/keyhelp genau ein Eintrag (Ausgabe gekürzt):

cat /etc/cron.d/keyhelp

MAILTO=""

# Minute Hour Day Month Day-Of-Week User Command
*/1 * * * * root nice -n 5 php /home/keyhelp/www/keyhelp/cronjob/mastercronjob.php

Dieser Mastercronjob läuft also jede Minute als root mit abgesenkter Priorität. Welche Jobs er bei einem Lauf startet, steht in seinem Protokoll. In den meisten Minuten war es nur „update“, um 19:35 UTC liefen zusätzlich Speicherplatz und Aufräumen:

grep "jobs to run" /var/log/keyhelp/cronjob/master.log

Auszug:

[PID-1152] [2026-10-01 19:35:05] INFO | jobs to run: update.php, diskspace.php, cleanup.php
[PID-1748] [2026-10-01 19:36:04] INFO | jobs to run: update.php
[PID-1793] [2026-10-01 19:37:01] INFO | jobs to run: update.php

Die systemd-Timer auf dem Server (systemctl list-timers) gehörten im Test alle zu Debian, etwa logrotate.timer und apt-daily.timer, keiner zu KeyHelp. Die Job-Skripte liegen unter /home/keyhelp/www/keyhelp/cronjob/jobs/. Was ein Job bei einem Lauf getan hat, lesen Sie in seinem Protokoll.

Verifizieren: Jeder Job hat in /var/log/keyhelp/cronjob/ eine eigene Logdatei, sobald er einmal gelaufen ist:

-rw-r--r-- 1 root    root      562 Oct  1 19:35 cleanup.log
-rw-r--r-- 1 root    root      998 Oct  1 19:35 diskspace.log
-rw-r--r-- 1 root    root    10670 Oct  1 19:39 master.log
-rw-r--r-- 1 root    root     1407 Oct  1 19:39 statistic.log
-rw-r--r-- 1 root    root     6148 Oct  1 19:39 update.log

Schritt 3: Einen Job mit keyhelp run starten

Das Kommandozeilenwerkzeug keyhelp beschreibt den Unterbefehl knapp:

keyhelp help run

Runs the maintenance interval with the given name.

Usage:
  keyhelp run [name]

Die gültigen Namen verrät der Befehl erst, wenn Sie einen falschen angeben. Interessanterweise liefert auch keyhelp run --help genau diese Meldung:

Maintenance job not found.
Valid jobs are: avscan, cleanup, diskspace, package-update, panel-update, php-update, ssh-chroot-update, ssl-maintenance, statistic, update

Warnung: Rufen Sie keyhelp run nie ohne Jobnamen auf, um die Hilfe zu sehen. Ohne Namen startet der Befehl im Test sofort und ohne Rückfrage den Job „update“ („Aufgaben abarbeiten“). Die Liste der gültigen Namen erhalten Sie gefahrlos mit einem ungültigen Namen oder mit keyhelp run --help.

Als Beispiel haben wir die Statistik sofort neu berechnen lassen, sonst ein stündlicher Job:

time keyhelp run statistic

sh: 1: dmidecode: not found
[PID-2255] [2026-10-01 19:39:02] INFO | maintenance connection okay
[PID-2255] [2026-10-01 19:39:02] INFO | forced to run "statistic.php"
[PID-2255] [2026-10-01 19:39:02] INFO | jobs to run: statistic.php
[PID-2255] [2026-10-01 19:39:02] INFO | >>> trying to run "statistic"
[PID-2255] [2026-10-01 19:39:02] INFO | lock "statistic" acquired
[PID-2255] [2026-10-01 19:39:02] INFO | processing the job ...
[2026-10-01 19:39:02] INFO | traffic calculation starts...
[2026-10-01 19:39:02] INFO | Collecting data for client "kunde1"
...
[2026-10-01 19:39:02] INFO | Awstats calculation starts...
[2026-10-01 19:39:02] INFO | Client "kunde1"
[2026-10-01 19:39:02] INFO | Domain "kunde1.server.example.de"
[2026-10-01 19:39:02] INFO | Update statistics...
...
[PID-2255] [2026-10-01 19:39:14] INFO | <<< job done, releasing lock "statistic"

real	0m12.010s

Der Befehl läuft im Vordergrund, schreibt sein Protokoll direkt ins Terminal und endet mit Rückgabewert 0. Die Zeile forced to run zeigt, dass der Job unabhängig von Intervall und Zeitfenster startet. Der Job setzt zu Beginn eine Sperre („lock … acquired“) und gibt sie am Ende wieder frei. Die Meldung dmidecode: not found erschien bei jedem Aufruf in unserer VM, hatte aber keinen Einfluss auf das Ergebnis.

Ebenso funktionierte die Zertifikatswartung, die sonst täglich zwischen 00 und 01 Uhr läuft:

keyhelp run ssl-maintenance

[2026-10-01 19:39:28] INFO | starting ssl certification maintenance
[2026-10-01 19:39:28] INFO | checking (normal) SSL/TLS certificates
[2026-10-01 19:39:28] INFO | check certificate "[ID 1]"
[2026-10-01 19:39:28] INFO | certificate name is "default"
[2026-10-01 19:39:28] INFO | certificate is valid until 2036-09-28 09:22:06 (3649 days left)
[2026-10-01 19:39:28] INFO | checking lets encrypt certificates
[2026-10-01 19:39:28] INFO | remove unused accounts / certificates
[2026-10-01 19:39:30] INFO | SNI configuration updated
[2026-10-01 19:39:30] INFO | finished

Verifizieren: Nach dem Lauf zeigt das Panel in der Spalte „Letzter Lauf“ den neuen Zeitpunkt, im Test „01. Okt. 2026, 19:39“ bei „Speicherplatz berechnen“ und „SSL/TLS-Zertifikate warten“ (siehe Screenshot in Schritt 1).

Die Jobs panel-update, package-update, php-update und avscan haben wir nicht manuell gestartet: Sie installieren Software oder führen einen Virenscan auf dem Server durch. Starten Sie diese nur bewusst und mit aktuellem Backup.

Schritt 4: „Jetzt starten“ im Panel

In der Spalte „Aktionen“ hat jede Zeile die Symbole „Bearbeiten“ und „Jetzt starten“, manche zusätzlich „Protokolle anzeigen“ und „Konfigurieren“. „Jetzt starten“ arbeitet anders als keyhelp run: Im Test startete der Job nicht sofort. Wir haben um 19:43:24 UTC „Jetzt starten“ bei „Aufräumarbeiten durchführen“ geklickt. Ausgeführt hat ihn der nächste Minutenlauf des Mastercronjobs:

[PID-3782] [2026-10-01 19:44:02] INFO | jobs to run: update.php, cleanup.php

Für eilige Fälle ist keyhelp run damit der direktere Weg, und Sie sehen die Ausgabe sofort.

Verifizieren: „Protokolle anzeigen“ verweist auf die passende Datei aus /var/log/keyhelp/cronjob/, bei den Aufräumarbeiten cleanup.log. Dort stand nach dem Lauf „Cleanup of temporary folders...“ und „Finished.“.

Schritt 5: Intervall oder Zeitfenster ändern

„Bearbeiten“ öffnet den Dialog „Einstellungen bearbeiten“ mit „Ist aktiviert“, „Intervall“ (Zahl plus „Minuten“, „Stunden“ oder „Tage“) und dem „Zeitfenster“ mit „Beginn des Ausführungszeitraums“ und „Ende des Ausführungszeitraums“ in vollen Stunden.

Lassen Sie die Werte im Normalfall, wie sie sind. Sinnvoll ist eine Änderung etwa, wenn Updates nicht in Ihr Wartungsfenster fallen: Dann verschieben Sie das Zeitfenster von „Control Panel aktualisieren“ oder „Server-Dienste aktualisieren“ entsprechend. Das Panel zeigt Zeiten in der Serverzeit an, im Test UTC. Ob das Zeitfenster nachts eingehalten wird, haben wir nicht abgewartet.

Verifizieren: Die Tabelle zeigt nach „Speichern“ die Meldung „Die Einstellungen wurden aktualisiert.“ und den neuen Wert. In der Datenbank stehen Intervall und Zeitfenster in keyhelp.maintenance_intervals.

Typische Fehler

• Intervall 0: Wir haben bei „Statistik aktualisieren“ das Intervall auf 0 gesetzt und das Zeitfenster auf „00 bis 00“. KeyHelp speicherte das ohne Warnung mit „Die Einstellungen wurden aktualisiert.“, die Tabelle zeigte „0 Stunden“. Danach lief die Statistik jede Minute mit:

  [PID-3183] [2026-10-01 19:41:02] INFO | jobs to run: update.php, statistic.php
  [PID-3377] [2026-10-01 19:42:01] INFO | jobs to run: update.php, statistic.php
  [PID-3566] [2026-10-01 19:43:02] INFO | jobs to run: update.php, statistic.php

  Ein manueller Lauf dauerte im Test 12 Sekunden. Prüfen Sie nach jeder Änderung die Zahl im Intervall.
• Tippfehler im Jobnamen: keyhelp run gibtsnicht endet mit „Maintenance job not found.“ und Rückgabewert 1. Die Namen weichen von den Skriptnamen ab: ssl-maintenance mit Bindestrich, das Skript heißt ssl_maintenance.php.
• keyhelp run ohne Namen: Der Befehl zeigt keine Hilfe, sondern startet sofort und ohne Rückfrage „update“ („forced to run "update.php"“), also „Aufgaben abarbeiten“, mit Rückgabewert 0. Auf unserem Testserver gab es nichts zu tun. Liegen Aufträge an, werden sie damit sofort abgearbeitet. Geben Sie den Jobnamen deshalb immer ausdrücklich an, auch in Skripten.

Häufige Fragen

Warum wirkt eine Änderung im Panel erst nach bis zu einer Minute?

Weil „Aufgaben abarbeiten“ (update) im Minutentakt läuft und erst dann Konfigurationsdateien schreibt. Im update.log sieht man das, etwa „Apache: reloading apache“ und „PHP-FPM (php8.2-fpm): reloading php-fpm“. Wer nicht warten will, startet keyhelp run update.

Kann ich die Wartung komplett abschalten?

Jeder Job hat einen Haken „Ist aktiviert“. Das Abschalten von „Aufgaben abarbeiten“ haben wir nicht getestet. Nach der Beschreibung im Panel erledigt dieser Job alles, was über das Panel in Auftrag gegeben wird, wie neue Kunden und Konfigurationsdateien.

Was bedeutet „von 00 bis 00 Uhr“?

Bei „Aufgaben abarbeiten“, „Speicherplatz berechnen“ und „Aufräumarbeiten durchführen“ steht das Zeitfenster ab Werk auf 00 bis 00. Im Test liefen „Speicherplatz berechnen“ und „Aufräumarbeiten durchführen“ um 09:27 und 19:35 UTC, das Fenster schränkte sie also nicht auf Mitternacht ein.

Testumfang

Getestet haben wir in KeyHelp 26.1.1 die Wartungsintervalle im Panel, den Mastercronjob, keyhelp run für statistic, diskspace, ssl-maintenance, cleanup und update, „Jetzt starten“ sowie Änderungen am Intervall. Auffällig: Intervall 0 wird ohne Warnung gespeichert. Update-, Virenscan- und PHP-Jobs haben wir nicht manuell gestartet, nächtliche Läufe nicht abgewartet. Kontrollieren Sie Ihre Intervalle nach Änderungen im Protokoll.

Fazit

Hinter den Wartungsintervallen von KeyHelp steckt ein einziger Cronjob, der jede Minute prüft, welcher Job fällig ist. Mit keyhelp run und den Logdateien unter /var/log/keyhelp/cronjob/ haben Sie diesen Ablauf im Griff: Sie sehen, was wann lief, und starten Speicherplatz, Statistik oder Zertifikatswartung bei Bedarf sofort. Ändern Sie Intervalle nur gezielt und prüfen Sie danach im master.log, ob der Job wie gewünscht läuft.

Weiterführende Anleitungen und Quellen

• KeyHelp installieren und absichern
• KeyHelp: SSL-Zertifikate mit Let's Encrypt und eigene Zertifikate überwachen
• Cron und crontab richtig nutzen: die Grundlagen
• KeyHelp-Changelog (Release Notes)
• Keyweb: KeyHelp, alle Funktionen im Überblick