Führen Sie mehrere Cron-Jobs aus, bei denen ein Job viel Zeit in Anspruch nimmt

Ich habe folgende allgemeine Frage zu Cronjobs.

Angenommen, ich habe Folgendes in meinem crontab:

* 10 * * * * someScript.sh
* 11 * * * * someScript2.sh
30 11 */2 * * someScript3.sh  <-- Takes a long time let's say 36 hours.
* 12 * * * someScript4.sh

Ist es klug genug, die verbleibenden Jobs zu den richtigen Zeiten auszuführen? Zum Beispiel muss das lange Skript nicht beendet werden?

Was passiert auch, wenn das erste lange Skript noch ausgeführt wird und es erneut von cron aufgerufen wird?

Vielen Dank!

Jeder Cron-Job wird unabhängig von anderen Jobs ausgeführt, die Sie möglicherweise angegeben haben. Dies bedeutet, dass Ihr langlebiges Skript andere Jobs nicht daran hindert, zum angegebenen Zeitpunkt ausgeführt zu werden.

Wenn eines Ihrer Skripte noch zum nächsten geplanten Cron-Intervall ausgeführt wird, wird eine andere, gleichzeitige Instanz Ihres Skripts ausgeführt.

Dies kann unvorhergesehene Konsequenzen haben, je nachdem, was Ihr Skript tut. Ich würde empfehlen , den Wikipedia - Artikel zu lesen File Locking , insbesondere der Abschnitt über die Lock - Dateien . Eine Sperrdatei ist ein einfacher Mechanismus, der signalisiert, dass eine Ressource - in Ihrem Fall das someScript3.shSkript - derzeit gesperrt ist (dh verwendet wird) und erst dann erneut ausgeführt werden sollte, wenn die Sperrdatei entfernt wurde.

In den Antworten auf die folgende Frage erfahren Sie, wie Sie eine Sperrdatei in Ihr Skript implementieren können:

• Wie kann sichergestellt werden, dass nur eine Instanz eines Bash-Skripts ausgeführt wird?

Nicht sicher, was Sie mit angemessener Zeit meinen. Cron startet die Jobs zum geplanten Zeitpunkt. Es werden weder andere geplante Jobs noch andere Instanzen eines Jobs überprüft.

Alle gültigen Jobs, die Sie definieren, werden zum festgelegten Zeitpunkt gestartet. Jeder Auftrag, der länger als das festgelegte Intervall ausgeführt wird, wird mehrmals gestartet. Es liegt in der Verantwortung desjenigen, der den Auftrag geschrieben hat, zu verhindern, dass er tatsächlich mehrmals ausgeführt wird, wenn dies erforderlich ist. Durch zB Überprüfung einer Sperrdatei oder PID-Datei oder etwas.

Die Anzahl der Prozesse, die parallel ausgeführt werden können, ist offensichtlich begrenzt, sie sind jedoch nicht Cron-spezifisch.

Zusätzlich zu anderen Antworten, insbesondere dem von @soulcake geposteten Link: Wenn Sie einen Befehl mit langer Laufzeit mit einem zu kurzen Intervall planen, führt cron den zweiten Befehl vor Abschluss des ersten Befehls problemlos aus (es sei denn, im Befehl ist eine Art Mutex implementiert). .

Dies verlangsamt den ursprünglichen Befehl häufig noch weiter und führt dazu, dass eine andere Instanz ausgeführt wird, bevor die vorherigen abgeschlossen sind usw. Oder es kann aus anderen Gründen unerwünscht sein.

Eine allgemeine Möglichkeit, dies zu verhindern, besteht darin, das Ausführen des Befehls mit einem Wächter zu bedingen, der sicherstellt, dass ein vorheriger Befehl nicht ausgeführt wird. Beispielsweise:

10 * * * * pgrep my_slow_command >/dev/null || /usr/local/bin/my_slow_command

Stellen Sie sicher, dass pgrep mit dem Namen des Befehls übereinstimmt, wenn es ausgeführt wird, z. B. haben Python-Skripte Python als Namen der ausführbaren Datei, was wahrscheinlich nicht spezifisch genug ist, und Sie müssten auch mit dem Skriptnamen des Pythons übereinstimmen.

10 * * * * pgrep -f my_script.py || /usr/local/bin/my_script.py

(pgrep ohne die Option '-f' stimmt jedoch mit den Namen der Bash-Skripte überein.)

Wenn Sie pgrep aus irgendeinem Grund nicht verwenden können:

10 * * * * ps ax | grep [m]y_command || /usr/local/bin/my_command

Die Klammern werden verwendet, um eine Übereinstimmung mit dem Befehl grep selbst zu vermeiden.

Ich benutze flock.

* * * * * exec flock --nonblock .ws_client.lock -c ws_client.py >& /tmp/ws_client.out