Ich habe den folgenden Code in meiner rootCrontab auf meinem Debian
* * * * * flock -xn /absolute/path/to/run.lock -c cd /absolute/parth/to/project && ./run >> run.log
Aber ich sehe keine run.logoder run.lockDateien, wo ich sie angebe. Tatsächlich gibt es keinen Beweis dafür, dass das Skript ausgeführt wurde.
ps aux | grep runNur das Ausführen führt zu diesem grepAufruf.
Wie führe ich das runSkript flockim Stammverzeichnis aus crontab?
Antwort1
Der Befehl in der Crontab-Zeile wird nicht wie erwartet analysiert.
Der Cron-Daemon führt den Befehl mithilfe der für den betreffenden Benutzer konfigurierten Shell aus.
Diese erste Shell sieht zwei Befehle, die durch den &&Kontrolloperator getrennt sind. Der zweite Befehl wird also nur ausgeführt, wenn der erste Befehl mit einem Null-Rückgabecode beendet wird, was auf Erfolg hinweist.
Der erste Befehl lautet: flock -xn /absolute/path/to/run.lock -c cd /absolute/path/to/project.
Der zweite Befehl lautet: ./run >> run.log.
Der erste Befehl erstellt die Sperrdatei und führt den Befehl cdals untergeordneten Prozess aus, d. h. in einer anderen Instanz der Shell. Der cdBefehl ohne Argumente wechselt in das Home-Verzeichnis des Benutzers, woraufhin die von ihm ausgeführte Shell flocksofort beendet wird. Dies hat im Endeffekt überhaupt keine Auswirkungen.
Selbst mit dem Pfadnamen cd /absolute/path/to/projecthätte der Befehl hier keinerlei Auswirkungen auf das Arbeitsverzeichnis des flockBefehls oder des zweiten Befehls, der von der ersten Instanz der Shell ausgeführt wird.Dies liegt daran, dass der cdBefehl nur die spezifische Shell-Instanz beeinflusst, in der er ausgeführt wird, nicht aber deren übergeordnete Instanzen.
Dies /absolute/path/to/projectwird als zusätzlicher Dateiname für den flockBefehl behandelt, nicht als Parameter für cd.
cronDa der erste Befehl beendet wurde und keine Fehler gemeldet hat, führt die erste Instanz der Shell (ursprünglich vom Daemon initiiert ) nun den zweiten Befehl aus. Da sich das Arbeitsverzeichnis dieser Shell nicht geändert hat, ist es immer noch das Home-Verzeichnis des rootBenutzers, sodass letztendlich versucht wird, das auszuführen, was tatsächlich /root/run >>/root/run.log.
Ich vermute, dass Sie wahrscheinlich so etwas meinten:
* * * * * flock -xn /absolute/path/to/run.lock -c "cd /absolute/path/to/project && ./run >> run.log"
Die Anführungszeichen verhindern, dass die erste Shell die Befehlszeile bei aufteilt &&. Dadurch flockerhält die zweite Shell (die durch den Befehl gestartet wurde) die gesamte verbleibende Befehlszeile, sodass der Befehl vor der Ausführung im Projektverzeichnis cd /absolute/path/to/projectsinnvoll ausgeführt wird ../run