Ich möchte Fehler bei einem Cron-Job beheben, der bis zu einer kürzlichen Änderung einwandfrei funktioniert hat, aber ich kann die Cron-Protokolldatei nicht finden. Wo ist sie?
Standardmäßig protokolliert Cron die Ausgabe ausgeführter Jobs nicht. Es ist möglich, die Ausführung von Cronjobs zu protokollieren, aber das ist auch nicht die Standardeinstellung unter OS X.
Um die Ausgabe der Cronjob-Ausführung zu untersuchen, schlage ich vor, Ihre Cronjob-Zeile zu ändern, um STDOUT und STDERR in Protokolldateien umzuleiten. Fügen Sie in Ihrer crontab-Datei oder nach dem Ausführen crontab -evon , wie auch immer Sie vorgehen, etwas wie das Folgende zu Ihrer Auftragszeile hinzu:
0 0 * * * yourcommand >/tmp/stdout.log 2>/tmp/stderr.log
Dadurch sollte STDOUT (normalerweise gedruckte oder als Echo ausgegebene Ausgabe an STDOUT) an eine Textdatei namens stdout.log im /tmp-Verzeichnis und STDERR an stderr.log im temporären Verzeichnis gesendet werden. Viele Dienstprogramme verwenden STDERR, um spezielle Fehlermeldungen auszugeben, wenn es sich um Anwendungsfehler handelt und nicht um Fehler, die durch die tatsächliche Ausführung des Programms generiert wurden. (Sie können mehr über STDERR auf Wikipedia lesen.)
cronder Job aus irgendeinem Grund überhaupt nicht ausgeführt. Wenn ich den Job selbst ausführe, indem ich den Befehl im Terminal eingebe, wird er ausgeführt und in die Protokolldatei ausgegeben, aber wenn ich darauf warte, dass croner ausgeführt wird, passiert nichts, zumindest keine Änderung in der Protokolldatei, ich dachte vielleicht an eine "Cron-Protokolldatei " oder es gab Spuren in der Konsole, die mir helfen könnten, herauszufinden, was los ist. Kürzlich habe ich meine Shell von bash auf zsh geändert, aber ich glaube nicht, dass dies dies auch beeinflusst haben könnte./System/Library/LaunchDaemons/com.vix.cron.plist) mit einem Stdout/Stderr-Pfad ändern, um Cron selbst zu debuggen. Ich kann mich nicht erinnern, ob es ausreicht, die Plist zu launchctl unloadsenden und zu senden, oder da es sich um einen Systemdämon handelt, wenn Sie vollständig neu starten müssten. launchctl loadIch würde letzteres vorschlagen, nur um sicherzugehen.Standardmäßig ist "Protokollierung" nicht aktiviert. Aber Sie können einige nützliche Informationen erhalten, indem Sie den mailBefehl ausführen.
TL; DR auf den mailBefehl: Drücken Sie die Eingabetaste, um Nachrichten zu lesen, und dann qund die Eingabetaste, um zu beenden.
Viel einfacher, einfach Folgendes hinzuzufügen /etc/syslog.conf:
cron.* /var/log/cron.log
Weisen Sie dann syslog an, seine Konfiguration neu zu laden:
sudo launchctl kill SIGHUP system/com.apple.syslogd.plist
oder um Folgendes hinzuzufügen /etc/asl/com.vix.cron(wodurch die Protokolldatei für Protokollkonsumenten wie Console.app auffindbar wird):
# Cron logging output, from the /System/Library/LaunchDaemons/com.vix.cron.plist launch daemon
> cron.log mode=0640 format=bsd rotate=seq compress file_max=5M all_max=50M
? [= Facility cron] [<= Level info] file cron.log
Getestet und funktioniert unter macOS 11.3
/etc/syslog.confsagt mein # Note that flat file logs are now configured in /etc/asl.conf. Diese Datei hat eine andere Syntax, es ist mir nicht klar, wie ich die Anmeldung konfigurieren soll./System/Library/LaunchDaemons/com.apple.syslogd.plist: Operation not permitted while System Integrity Protection is engaged/etc/asl/com.vix.cron.sudo launchctl kill SIGHUP system/com.apple.syslogd, kein vollständiger Neustart erforderlich.Ich konnte Cron-Job-Login finden,
/var/mail/{user-name}
Es folgt ein Cron-Job-Protokoll, das ich für die Ausführung eines AWS CLI-Befehls erhalten habe.
From build@BuildServer1.local Fri Mar 2 10:00:00 2018
Return-Path: <build@BuildServer1.local>
X-Original-To: build
Delivered-To: build@BuildServer1.local
Received: by BuildServer1.local (Postfix, from userid 501)
id A7A94296CBA3; Fri, 2 Mar 2018 10:00:00 +0100 (CET)
From: build@BuildServer1.local (Cron Daemon)
To: build@BuildServer1.local
Subject: Cron <build@BuildServer1> /app/scripts/s3-sync.sh
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=build>
X-Cron-Env: <USER=build>
X-Cron-Env: <HOME=/Users/build>
Message-Id: <20180302090000.A7A94296CBA3@BuildServer1.local>
Date: Fri, 2 Mar 2018 10:00:00 +0100 (CET)
upload: ../../app/logs/debug.log to s3://**my-s3***/app/logs/debug.log
userStellte sich heraus, als cronder Job (wie ich) ausgeführt wurde, /usr/local/binwar nicht in der PATH.
Ich fand dies durch Versuch und Irrtum und baute den Job von Grund auf aus einfachen Dingen auf, von denen ich wusste, dass sie funktionieren würden, und fügte nach und nach Dinge hinzu, bis ich das Problem fand.
Zu den anderen Vorschlägen und Antworten:
Aus irgendeinem Grund (zumindest auf meinem Computer, auf dem ein von SnowLeopard aktualisierter Lion ausgeführt wird) cronwerden die in den Plist-Dateien angegebenen Parameter nicht verwendet, die launchdgelesen werden sollen, /System/Library/LaunchDaemons/com.vix.cron.plistoder vielleicht schreibt Cron auf Lion nichts zu stdout oder stderr.
Übrigens verwende ich http://s3tools.org/s3cmd zu synceinem Ordner mit einem Amazon S3-Bucket als Backup (wie eine primitive DropBox).
Jaberg
daviesgeek
Ali
cronJob, mit dem ich es eingerichtet habe,cron -eund ich kann es sehen,cron -lund ich bin sicher, dass es lange Zeit bei Lion und davor bei Snow Leopard funktioniert hat.Ali
Jason Salaz