sh-Skript mit Aufgabenplaner ausführen - output.log nur über die konsole lesbar

[Milchman]

Hallo,

bisher habe ich immer ein Skript mit verschiedenen Jobs / RSYNC-Aufgaben täglich ausgeführt. Hier ein Ausschnitt:

#!/bin/sh
date +"%d-%m-%Y - %H:%M:%S"
docker exec mariadb sh -c 'exec mysqldump --all-databases -uroot -p"<password>"' | gzip -c | cat > /volume1/backups/mariadb/$(date +%Y-%m-%d-%H.%M.%S).sql.gz
find /volume1/backups/mariadb/*.sql.gz -type f -mtime +28 -delete &> /dev/null
date +"%d-%m-%Y - %H:%M:%S"
echo -e "Alle Datenbanken des mariadb-Container nach /volume1/backups/mariadb gesichert und Backups älter als 28 Tage gelöscht\n\n"

Bis vor einigen Monaten hat er dann brav immer ein output.log und ein script.log unter /volume1/jobs/... abgelegt.
Das macht er immer noch, aber über den Filestation sind diese Files nicht mehr lesbar. Nur über die Konsole

Kann man das wieder ändern? Ist vermutlich mit dem Update von DSM6 nach DSM7 passiert.

Am besten er sendet mir den Inhalt des output.log per Mail. Aber hier kommt nichts an:

 

[Tommes]

Hi!

Bis vor einigen Monaten hat er dann brav immer ein output.log und ein script.log unter /volume1/jobs/... abgelegt.
Das macht er immer noch, aber über den Filestation sind diese Files nicht mehr lesbar. Nur über die Konsole

Vermutlich liegt hier nur ein Rechteproblem vor, da du das Script mit Sicherheit als root ausführst. Dem zur Folge werden auch die Protokolldateien output.log und script.log mit den Rechten für root versehen. Das würde zumindest erklären, warum du die Dateien über die FileStation unter DSM 7 nicht mehr öffnen kannst. Dir fehlen einfach die Rechte. Umstellen kannst du das entweder in der Filestation selbst, sympatischer fände ich jedoch, das du das über dein Script löst mit z.B. chmod 777 output.log bzw. chmod 777 script.log

Am besten er sendet mir den Inhalt des output.log per Mail. Aber hier kommt nichts an

Soweit ich weiß, handelt es sich bei den Ausführungsdetails, die dir nach der Ausführung der Aufgabe per Mail zugesendet werden um Ausgaben, die durch stdout und stderr erzeugt werden. Da du das Logging jedoch in Dateien umleitest, folgt auch keine Ausgabe auf stdout und stderr, weshalb die Mail leer bleibt.

Was du machen könntest - und so mach ich das bei der Protokollerstellung von Basic Backup - wäre, die Ausgabe sowohl in eine Datei zu leiten, als auch auf der Konsole (stdout) ausgeben zu lassen. Das geht mit dem tee Befehl.

Beispiel:

echo "Ich werde auf stdout ausgegeben und in eine Datei geschrieben" | tee -a /var/log/irgendwas.log

Schau mal, ob dich das weiter bringt.

Tommes

 

[geimist]

Da du das Logging jedoch in Dateien umleitest, folgt auch keine Ausgabe auf stdout und stderr, weshalb die Mail leer bleibt.

Ich habe das nicht so verstanden. Aber der Haken muss entfernt werden, dass das Log lediglich bei einem Fehler gemailt wird, wenn du es immer erhalten möchtest.

 

[Tommes]

Jetzt wird es wieder lustig. Ich habe es so verstanden, das er sich entweder die Logfiles direkt im DSM mittels der FileStation und ggf. dem installierten TextEditor anzeigen lassen möchte.

Oder aber er möchte sich die Protokolle direkt per Mail senden lassen. Das kann der Aufgabenplaner meines Erachtens jedoch nicht, das müsste er dann wohl schon direkt über das Script mittels z.B. ssmtp o.ä. passieren.

Der Aufgabenplaner fängt meines Erachtens nur die Standardausgabe stdout und ggf. stderr ab und sendet dieses dann per Mail weg. Wenn aber nichts ausgeben wird mit z.B. -verbose oder so, kommt auch keine Mail an. Daher der Tipp oder Trick mit tee.

Aber hören wir mal, was der TE zu sagen hat bevor das wieder eskaliert. Obwohl das ja eher nur dann passiert, wenn ich und @luddi zusammen in einem Thread rumwuseln.

 

[geimist]

Es geht ja beides. Man kann ja in den Logordner, den man über den Aufgabenplaner ➜ Einstellungen definiert, auch direkt reingucken, was er wohl so gemacht hat, wie ich das verstanden habe. Aufgrund der root-Rechte geht das nun nicht (übrigens würde ich chmod -R 774 auf den ganzen Ordner setzen, weil man ja noch nicht den Namen des aktuellen Logs kennt).

Der Mailversand funktioniert auch parallel – auch mit stdout, sofern man den Haken weglässt. Ist der Haken gesetzt, wird nur bei einem Exitcode ungleich 0 gemailt.

 

[luddi]

wenn ich und @luddi zusammen in einem Thread rumwuseln.

Aus besagtem Grund halte ich mich wohl besser zurück bevor wir beide im Verbund für komplette Verwirrung sorgen würden

 

[Milchman]

sympatischer fände ich jedoch, das du das über dein Script löst mit z.B. chmod 777 output.log bzw. chmod 777 script.log

Ja, klappt bei mir aber nicht. Da er nicht weiss, wo die Dateien liegen. Sie werden ja in zwei Unterverzeichnissen mit Timestamp gespeichert. Hat jemand eine Idee?

 

[Tommes]

Ich kann dir nicht folgen.

 

[geimist]

Ja, klappt bei mir aber nicht. Da er nicht weiss, wo die Dateien liegen. Sie werden ja in zwei Unterverzeichnissen mit Timestamp gespeichert. Hat jemand eine Idee?

Hab ich doch geschrieben: chmod -R 774 /logverzeichnis
Möglicherweise greift das aber jeweils nicht für das aktuelle Log, sofern das erst nach Abschluss der Aufgabe geschrieben wird.

Ich kann dir nicht folgen.

Das im Aufgabenplaner definierte Verzeichnis enthält für jede Aufgabe ein eigenes Unterverzeichnis. Beim Ausführen der Aufgabe kennt sein Skript ja nicht den Pfad der aktuellen Logdatei, die vom Aufgabenplaner angelegt wird.

 

[Benares]

@Milchman,
schau dir nochmal den Trick von @Tommes aus #2 an. Das Problem ist, dass der Aufgabenplaner, nur das als Mail verschickt, was dein Script auf der Konsole ausgibt (stdout, stderr). Willst du zusätzlich ein Logfile, musst du die Ausgabe an "tee" "pipen" (|) und nicht direkt in ein Logfile schreiben (> bzw. >>). tee bildet sowas wie ein T-Stück (daher der Name). Die Ausgabe landet dann auf der Konsole und im angegeben Logfile (s. hier).

 

[geimist]

Es wird beides ausgegeben.

Hier der Log-Ordner vom Aufgabenplaner (das entsprechende Log muss man erst mal finden ):
/volume1/krimskrams/@Logfiles/synoscheduler/9/1677519781/output.log

27-02-2023 - 18:43:01
27-02-2023 - 18:43:01
Alle Datenbanken des mariadb-Container nach /volume1/backups/mariadb gesichert und Backups älter als 28 Tage gelöscht

Und die Mail sieht so aus, sofern man den Haken nicht setzt, dass sie nur bei Fehler geschickt wird:

Aufgabe: TEST
Start: Mon, 27 Feb 2023 18:41:01 GMT
Ende: Mon, 27 Feb 2023 18:41:01 GMT
Aktueller Status: 0 (Normal)
Standardausgabe/Fehler:
27-02-2023 - 18:41:01
27-02-2023 - 18:41:01
Alle Datenbanken des mariadb-Container nach /volume1/backups/mariadb gesichert und Backups älter als 28 Tage gelöscht

Aber die Lösung mit tee ist sicherlich die eleganteste:

/volume1/jobs/rsync.sh | tee -a /volume1/jobs/rsync.sh.log

 

[Benares]

Wusste ich nicht, Danke für den Hinweis. Aber dann bastelt der Aufgabenplaner wohl noch selbst etwas drumrum.
Klappt das auch, wenn man direkt in ein Log schreibt, beispielweise mit

/volume1/jobs/rsync.sh >> /volume1/jobs/rsync.sh.log 2>>&1

?
Dann kommt m.W. auf der Konsole gar nichts mehr raus