Lösung für das Problem, dass die Umleitung der Crontab-Ausgabe unter Linux nicht wirksam wird

Frage

Unter LINUX werden periodische Aufgaben normalerweise vom Cron-Daemon-Prozess [ps -ef | grep cron] ausgeführt. Cron liest eine oder mehrere Konfigurationsdateien, die Befehlszeilen und die Zeiten enthalten, zu denen sie aufgerufen werden.

Die Cron-Konfigurationsdatei heißt „crontab“, die Abkürzung für „Cron Table“.

Vor kurzem wurde eine geplante Aufgabe zu crontab hinzugefügt. Nach der Ausführung der Aufgabe erfolgt standardmäßig eine normale Ausgabe. Um sicherzustellen, dass die Ausnahmeinformationen während der Aufgabenausführung auch erfasst werden können und die Problemlokalisierung erleichtert wird, habe ich einen solchen Befehl in crontab geschrieben:

01 09 * * * cd /opdir/test/ && ./test.sh &>>test.log

Der obige Befehl ist sehr einfach zu verstehen. Er führt das Skript test.sh jeden Tag um 9:01 aus und leitet die Standardfehlerausgabe und die Standardausgabe des Skripts in die Datei test.log um. Schließlich stellte sich heraus, dass das Skript normal ausgeführt wurde, die Protokolldatei test.log jedoch keinen Inhalt enthielt.

Um dieses Problem zu lösen und zu erklären, stellen wir zunächst kurz das Problem der Umleitung im Linux-System vor.

Konzept

Linux:

1: gibt die Standardausgabe (stdout) an, die standardmäßig auf dem Bildschirm ausgegeben wird

2: bezeichnet die Standardfehlerausgabe (stderr), die standardmäßig auf dem Bildschirm ausgegeben wird

Normalerweise verwenden wir häufig die folgende Methode, um die Ergebnisse der Skriptausführung umzuleiten:

bash test.sh >test.out //Die Standardausgabe des Skripts wird in die Datei test.out geschrieben und die Standardfehlerausgabe direkt auf dem Bildschirm gedruckt. Entspricht: bash test.sh 1>test.out
bash test.sh >test.out 2>&1 //Sowohl die Standardausgabe als auch die Standardfehler werden in test.out geschrieben und überschreiben sich nicht gegenseitig, was bash test.sh &>test.out entspricht
bash test.sh >test.out 2>test.out //Sowohl die Standardausgabe als auch die Standardfehlerausgabe werden in test.out geschrieben, was sich gegenseitig überschreiben kann. Es wird nicht empfohlen, bash test.sh &>test.out zu verwenden //Entspricht der zweiten Methode

Vergleichen Sie die obigen Effekte:

Der erste Typ: Fehlerausgabe erfolgt auf dem Bildschirm, normale Ausgabe erfolgt in der Datei test.out

root@mengalong:~/opdir/mengalong/t/t# cat test.sh
#!/bin/bash
T
Datum

root@mengalong:~/opdir/mengalong/t/t# bash test.sh >test.out
test.sh: Zeile 2: t: Befehl nicht gefunden
root@mengalong:~/opdir/mengalong/t/t# cat test.out
Mittwoch, 31. Oktober 2018, 11:07:24 CST

Der zweite Typ: Sowohl die Fehlerausgabe als auch die normale Ausgabe werden in die Datei test.out umgeleitet

root@mengalong:~/opdir/mengalong/t/t# bash test.sh >test.out 2>&1
root@mengalong:~/opdir/mengalong/t/t# cat test.out
test.sh: Zeile 2: t: Befehl nicht gefunden
Mittwoch, 31. Oktober 2018, 11:09:02 CST

Der dritte Typ: Fehlerausgabe und normale Ausgabe überdecken sich gegenseitig

root@mengalong:~/opdir/mengalong/t/t# bash test.sh >test.out 2>test.out
root@mengalong:~/opdir/mengalong/t/t# cat test.out
Mittwoch, 31. Oktober 2018, 11:10:36 CST
nicht gefunden

Viertens, Sonderfall, vergleichen Sie den Unterschied zwischen bash test.sh 2>&1 >test.out und bash test.sh >test.out 2>&1:

root@mengalong:~/opdir/mengalong/t/t# bash test.sh 2>&1 >test.out
test.sh: Zeile 2: t: Befehl nicht gefunden
root@mengalong:~/opdir/mengalong/t/t# cat test.out
Mittwoch, 31. Oktober 2018, 11:12:13 CST

Hier setzen wir einfach 2>&1 vor >test.out, aber das Ergebnis ist nicht das erwartete. Sowohl die Fehler- als auch die normale Ausgabe gehen in die Datei test.out. Dies liegt daran, dass im Befehl bash test.sh 2>&1 >test.out 2>&1 die Fehlerausgabe nur an die Standardausgabe umleitet und der Standardwert der Standardausgabe zu diesem Zeitpunkt der Bildschirm ist. Dies ist also tatsächlich gleichbedeutend damit, dass die Standardfehlerausgabe auf den Bildschirm statt in die Datei umgeleitet wird. Daher muss die Umleitungsreihenfolge berücksichtigt werden.

Problemlösung

Schauen wir uns als Nächstes die Crontab-Aufgabe an, die ich geschrieben habe:

01 09 * * * cd /opdir/test/ && ./test.sh &>>test.log

Gemäß der obigen konzeptionellen Analyse sollte diese Schreibmethode äquivalent zu ./test.sh >test.log 2>&1 sein. Die Ausgabe der Skriptausführung und die Standardfehlerausgabe werden alle nach test.log umgeleitet. Tatsächlich ist es aber so, dass die Datei test.log nichts enthält.

Dies liegt daran, dass die von crontab verwendete Standard-Shell-Umgebung /bin/sh ist und /bin/sh die Umleitungsmethode von &>>test.log nicht unterstützt. Daher sehen wir, dass test.log keinen Inhalt enthält.

Daher besteht die Lösung des Problems darin, die Umleitungsmethode von Crontab zu ändern:

01 09 * * * cd /opdir/test/ && ./test.sh >>test.log 2>&1

Ein Ratschlag

Wenn die Skriptausgabe während der Crontab-Ausführung nicht umgeleitet wird, wird standardmäßig eine E-Mail an den Systembenutzer gesendet. Der E-Mail-Inhalt wird im Allgemeinen in /var/mail/$user gespeichert. Wenn er nicht bereinigt wird, wird die Stammpartition des Servers voll, was schließlich dazu führt, dass sich der Computer nicht mehr anmelden kann. Daher lautet der empfohlene Crontab-Befehl wie folgt:

01 09 * * * cd /opdir/test/ && ./test.sh >>test.log 2>&1 </dev/null &

Insbesondere wird am Ende </dev/null & hinzugefügt. Ich werde die Bedeutung davon nicht im Detail erklären. Wenn Sie interessiert sind, können Sie es selbst analysieren.

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Wenn Sie Fragen haben, können Sie eine Nachricht hinterlassen. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.