Cron Ausdruck für jede Minute: * * * * *

Der Ausdruck * * * * *

Der Cron Ausdruck * * * * * löst zu jeder Minutenmarke aus: 00:00, 00:01, 00:02 und so weiter, insgesamt 60 Mal pro Stunde, 1440 Mal pro Tag. Ein nacktes * in einem Cron Feld bedeutet “jeder gültige Wert in diesem Feld.” Wenn alle fünf Felder auf * gesetzt sind, gibt es keinen Filter: Der Job läuft an jeder möglichen Zeitplangrenze.

Dies ist die maximale Häufigkeit, die Cron unterstützt. Das Minutenfeld ist die feinste Granularität, die Cron hat, also ist * * * * * so schnell, wie Cron nur sein kann.

Wann ein Pro-Minute Zeitplan sinnvoll ist

Queue Worker mit Cron-basiertem Auslöser

Einige Systeme verwenden Cron, um einen Worker zu starten, der eine Job Warteschlange abarbeitet. Wenn Jobs kontinuierlich eintreffen und die Latenz wichtig ist, stellt ein Pro-Minute Auslöser sicher, dass die Warteschlange nicht lange untätig bleibt. Eine ordentliche Message Queue mit einem Long Polling Consumer ist jedoch eine sauberere Architektur für dieses Muster.

Echtzeit Monitoring ohne dedizierten Agenten

Wenn du keinen persistenten Überwachungsagenten installieren kannst, ist ein Pro-Minute Cron, der einen Health Endpunkt überprüft oder eine Metrik protokolliert, ein pragmatischer Fallback. Er wird keine Fehler erkennen, die innerhalb von 60 Sekunden auftreten und wieder verschwinden, aber er ist besser als ein Polling alle 5 Minuten für einen kritischen Dienst.

Leichte Heartbeat Signale

Das Schreiben eines Zeitstempels in eine Datei oder Datenbank jede Minute ist eine übliche Lebendigkeitsprüfung. Einige Dead Man’s Switch Implementierungen sind darauf angewiesen. Wenn der Heartbeat nicht mehr aktualisiert wird, wird ein Alarm ausgelöst.

Wann es übertrieben ist

Alles mit einer natürlichen Batch Grenze

Wenn du Berichte erstellst, Daten synchronisierst oder Benachrichtigungen sendest, frage dich, ob Benutzer tatsächlich Aktualisierungen jede Minute benötigen. Die meisten “nahezu Echtzeit” Anforderungen werden durch ein 5 Minuten Intervall erfüllt. Ein Pro-Minute Cron wird oft standardmäßig gewählt und nie überdacht.

Jobs mit erheblichen Startkosten

Wenn dein Job eine Verbindung zur Datenbank herstellt, Konfiguration aus einer entfernten Quelle lädt oder sich gegen eine externe API authentifiziert, bezahlt er diese Kosten 1440 Mal am Tag. Ein langlebiger Daemon bezahlt sie einmal.

Jobs, die manchmal länger als 60 Sekunden brauchen

Standard Cron weiß nicht, ob der vorherige Lauf noch ausgeführt wird. Wenn der Job 90 Sekunden dauert, hast du in Minute 2 zwei Instanzen, die gleichzeitig laufen. Dies führt zu Wettlaufsituationen, doppelter Arbeit und Ressourcenkonflikten.

Gleichzeitige Ausführung verhindern

Für jeden Pro-Minute Cron Job teste, was passiert, wenn die Ausführungszeit 60 Sekunden überschreitet. Der Standard Fix ist flock:

* * * * * flock -n /tmp/myjob.lock /pfad/zu/myjob.sh

flock -n erwirbt eine exklusive Sperre auf die Datei. Wenn ein vorheriger Aufruf die Sperre noch hält, wird der neue sofort beendet. Dies verhindert Überlappungen, ohne den laufenden Job zu beenden.

Alternativ verwende eine PID Datei Prüfung in deinem Skript oder ein dediziertes Tool wie run-one auf Debian basierten Systemen:

* * * * * run-one /pfad/zu/myjob.sh

Subminuten Alternativen

Wenn eine Minute zu langsam ist, sind dies die echten Optionen:

systemd Timer mit einer Sleep Schleife

Erstelle eine .service Unit, die intern loopt, und eine .timer Unit, die sie beim Start startet. Der Dienst führt while true; do /pfad/zu/task; sleep 10; done aus. Du erhältst Subminuten Ausführung mit ordnungsgemäßem Neustartverhalten und Journal Protokollierung.

Sleep basierter Doppeleintrag (30-Sekunden Workaround)

Zwei crontab Zeilen:

* * * * * /pfad/zu/job
* * * * * sleep 30 && /pfad/zu/job

Dies nähert ein 30-Sekunden Intervall an. Es ist unter Last fragil, funktioniert aber für Aufgaben mit geringem Risiko.

Celery Beat / APScheduler / ähnliche

Anwendungslevel Scheduler laufen in deinem Prozess und unterstützen beliebige Intervalle, einschließlich Subsekunden. Wenn du bereits einen Python oder Node.js Dienst betreibst, sind diese Cron für hochfrequente Aufgaben vorzuziehen.

Kubernetes CronJobs

Kubernetes CronJobs haben dasselbe 1-Minuten Minimum wie System Cron. Für Subminuten Workloads in Kubernetes verwende ein Deployment mit einer Schleife im Container, keinen CronJob.

Ausführung überprüfen

Bei aktivem * * * * * solltest du 60 Log Einträge pro Stunde sehen. Überprüfe auf Linux:

grep CRON /var/log/syslog | grep myjob | tail -5

Oder mit systemd:

journalctl -u cron --since "1 hour ago" | grep myjob

Wenn du Lücken in der Pro-Minute Kadenz siehst, untersuche: durchschnittliche Auslastung, Festplatten I/O Wartezeit oder ein Sperrkonfliktproblem durch überlappende Läufe.