staging.inyokaproject.org

Hallo, ich möchte ein Script zur Datensicherung per crontab abarbeiten und als visuelle Rückmeldung sowie Info zum Zeitpunkt der Ausführung ein zusätzliches Teminal-Fenster aufpoppen lassen welches sich nach Abarbeitung des Scripts wieder schließt. Soweit so gut, das Mini-Script an sich funktioniert wie gewünscht wenn ich es aus der Shell direkt aufrufe - was partout nicht gelingen will ist der Aufruf des Scripts durch crontab.

Nach Recherche im Netz ist der letzte Stand folgender Ausdruck dessen Funktinalität aus einem zusätzlichen Hilfsscript getestet wurde, also Script-A ruft Script-B auf, aber weiterhin direkt aus einer aktiven Shell.

1

gnome-terminal -- sh -c "bash -c \"/pfad/SaveData.sh; exec bash\""

Jedoch der Ausdruck, so wie aufgeführt, in einem crontab hinterlegt hat keinerlei Auswirkung, das Script wird nicht aufgerufen wobei die Zugriffsrecht mit chmod 775 wohl ok sein sollen und die PATH-Variable auch korrekt ist.

Ein "tail -F /var/log/auth.log" zeigt zwar an das minütlich im crontab etwas angestossen aber auch sofort wieder geschlossen wird.

1
2

Mar 10 01:17:01 yoga CRON[120460]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Mar 10 01:17:01 yoga CRON[120460]: pam_unix(cron:session): session closed for user root

Was mir in dem Zusammenhang nicht eingehen will ist der Verweis auf "user root" da es sich um einen normalen user-crontab handelt der mit "crontab -e" bearbeitet wurde aber auch der Aufruf mit dem System-crontab (/etc/crontab) schlägt fehl.

Lediglich der direkte Eintrag der rsync-Befehlszeile in den crontab funktioniert und sichert entsprechend die Daten.

1

*/1 * * * * rsync -ravh --del --progress -e 'ssh -i /home/... etc.

Hat jemand einen Tipp?

Gruß pac

gnome-terminal ist eine Grafische Anwendung, diese braucht (z.B.) den X-Server/Xorg um was anzeigen du können. Also muss mindestens die DISPLAY Variable passend gesetzt sein.

pacmexx schrieb:

Hat jemand einen Tipp?

Lies den UbuntuUsers-de-Wiki-Artikel zu cron!

Der Aufruf von GUI-Programmen aus einer Crontab bedarf besonderer Prozeduren.

Die Auffälligkeit mit dem Verweis auf "user root" in "/var/log/auth.log" ist auf einen reproduzierbaren Fehler meinerseits zurückzuführen und stammt aus dem root-crontab mit dem auszuführenden user:root, setze ich den user:puc erscheint entsprechend auch der korrekte user im Eintrag von auth.log. - das Script wird jedoch immer noch nicht ausgeführt.

Die DISPLAY-Variable wurde im Script erstmal auf DISPLAY:=0 gesetzt - ohne Ergenis. Jellyfish nutz Wayland, was die Überprüfung von $XDG_SESSION_TYPE ergab. Der rudimentäre Versuch die DISPLAY-Variable dahingehend zu setzen scheint so keinen Sinn zu machen.

DISPLAY:=$XDG_SESSION_TYPE oder DISPLAY:=$WAYLAND_DISPLAY

Wie würde die korrekt Syntax aussehen?

Hallo,

dein Kernproblem ist IMHO: du arbeitest gegen das System. systemd Timer Units und das ältere / angestaubte Cron sind dafür gemacht, Programme / Skripte periodisch im Hintergrund auszuführen und _nicht_ automagisch ein Fenster im Vordergrund zu öffnen, wo man dann irgendwelche Ausgaben sieht. Wenn dein Skript Ausgabe generiert, dann halt in eine Log-Datei.

Es gibt Workarounds, um ggf. Fenster zu öffnen - aber das ist halt tricky. Und es sind Workarounds, mit denen man irgendwie versucht, das System zu umgehen. Erschwerend kommen noch zwei Sachen hinzu: Einträge in einer der Cron Dateien werden standardmäßig von systemd ausgeführt, nicht mehr von Cron. D.h. wenn du einen Hack für Cron anwendest könnte es sein, dass das unter systemd so nicht funktioniert. Zum anderen verwendet Ubuntu seit 22.04 standardmäßig Wayland als Grafikserver und als Teil des Sicherheitskonzept blockt Wayland Fenster, die mit Root-Rechten aufgerufen werden wollen. Wenn dein Skript Root-Rechte braucht hast du hier einen Konflikt.

Gruß, noisefloor

Ok, danke für die Info, dann ist die angestrebte Vorgehensweise obsolet. In welche Richtung müsste ich den denken um meine Vorstellung umzusetzen, ein Link zum Einstieg wäre nett?

pacmexx schrieb:

Die Auffälligkeit mit dem Verweis auf "user root" in "/var/log/auth.log" ist auf einen reproduzierbaren Fehler meinerseits zurückzuführen und stammt aus dem root-crontab mit dem auszuführenden user:root, setze ich den user:puc erscheint entsprechend auch der korrekte user im Eintrag von auth.log. - das Script wird jedoch immer noch nicht ausgeführt.

Keine Ahnung, was du damit meinst. Tut in diesem Kontext wohl auch nichts zur Sache.

Die DISPLAY-Variable wurde im Script erstmal auf DISPLAY:=0 gesetzt - ohne Ergenis. Jellyfish nutz Wayland, was die Überprüfung von $XDG_SESSION_TYPE ergab.

Korrekt.

Der rudimentäre Versuch die DISPLAY-Variable dahingehend zu setzen scheint so keinen Sinn zu machen.

Wie kommst du denn auch auf solche Ideen? Wenn du dir den Artikel, den kB dir verlinkt hat, aufmerksam durchgelesen hättest, insbesondere diesen Abschnitt, dann hättest du von selbst darauf kommen können, dass

DISPLAY:=$XDG_SESSION_TYPE oder DISPLAY:=$WAYLAND_DISPLAY

beides Unfug ist. Statt dessen hätte dich

echo $XDG_RUNTIME_DIR 

/run/user/1000

und entsprechend dann der Eintrag im Skript:

XDG_RUNTIME_DIR=/run/user/1000

eher zum Ziel geführt.

Nachtrag: Getestet habe ich das anhand von Ubuntu 23.10 in der Virtual Box mit dem folgenden Skript:

1
2
3
4

#!/bin/sh
arbverz=/home/benutzer/Pfad/zum/Arbeitsverzeichnis
XDG_RUNTIME_DIR=/run/user/1000 notify-send -t 5000 "Info" "Dieser Text wird in der Box angezeigt."
echo "Das Skript wurde um $(date +%X) per Cron-Job aufgerufen." >> $arbverz/Notiz.txt

Edit: Code sinnvoll ergänzt.

wxpte schrieb:

pacmexx schrieb:

Die DISPLAY-Variable wurde im Script erstmal auf DISPLAY:=0 gesetzt - ohne Ergenis. Jellyfish nutz Wayland, was die Überprüfung von $XDG_SESSION_TYPE ergab.

Korrekt.

Da habe ich selbst nicht aufgepasst: Nein, eben nicht korrekt. Die Umgebungsvariable heißt DISPLAY, also muss die Zuweisung auch DISPLAY=:0 lauten, wegen:

echo $DISPLAY 

:0

Aber ansonsten gilt das oben geschriebene: die Umgebungsvariable XDG_RUNTIME_DIR ist bei Wayland relevant.

Ok, danke erstmal - das mit dem "notify-send" funktioniert, dann halt ohne fancy Terminal-PopUp.

pacmexx schrieb:

... dann halt ohne fancy Terminal-PopUp.

Ob ein Terminal-PopUp inklusive Ausgabe des über Cron laufenden Skripts jemals funktioniert hat, weiß ich nicht. Ich halte das auch für ziemlich sinnfrei.

noisefloor schrieb:

Es gibt Workarounds, um ggf. Fenster zu öffnen - aber das ist halt tricky. Und es sind Workarounds, mit denen man irgendwie versucht, das System zu umgehen.

Das würde ich so nicht formulieren. Das Programm cron muss unabhängig von einem Grafikserver laufen, einmal, weil es so auch in Serversystemen ohne Grafikdisplay verwendet wird, einmal, da es schon vor dem Start des XServers oder Waylands Aufgaben zu erledigen haben kann.

Es ist daher nicht als Aussperrung von X zu begreifen, wenn das nicht reibungslos gestartet werden kann.

Linux ist eben auch ein Desktopsystem und gerade hier im Forum ist wohl der Großteil - vielleicht nicht ausschließlich, aber doch auch - Desktopuser. Und auf dem Desktop will man eben auch Fenster aufpoppen sehen - nicht jeder, womöglich die meisten nicht, aber man funkt dem System nicht ins Getriebe, wenn man grafische Programme aus Cron aufruft. Man muss eben vorher XDG_RUNTIME_DIR setzen, und das war's.

Man macht sich dabei nicht schmutzig und auch das System nicht.

Erschwerend kommen noch zwei Sachen hinzu: Einträge in einer der Crondateien werden standardmäßig von systemd ausgeführt, nicht mehr von Cron.

So, so, ist das so?

1
2
3

ps -C cron 
    PID TTY          TIME CMD
    991 ?        00:00:00 cron

Gut - es wäre mir zuzutrauen, dass ich manuell auf 2 Rechnern cron installiert habe, aber wenn systemd das reibungslos übernommen hätte, dann

• stellt sich die Frage, wieso dann cron im Arbeitsspeicher bei mir ist (22.04)

• kann es uns wurscht sein, solange das Setzen von XDG… von systemd klaglos umgesetzt wird, und entweder das wird es, oder die Aussage, dass systemd cron vollständig übernommen hat, stimmt (so pauschal) nicht. Jedenfalls laufen bei mir täglich viele Desktopnotifications und das seit Monaten.

D.h. wenn du einen Hack für Cron anwendest könnte es sein, dass das unter systemd so nicht funktioniert.

Doch, doch, funktioniert ganz fluffy.

Zum anderen verwendet Ubuntu seit 22.04 standardmäßig Wayland als Grafikserver und als Teil des Sicherheitskonzept blockt Wayland Fenster, die mit Root-Rechten aufgerufen werden wollen. Wenn dein Skript Root-Rechte braucht hast du hier einen Konflikt.

Das hätte er dann, i.d. Tat, aber kein unlösbares.

Schwieriger wird es, wenn ein Skript für User pacmexx und pacmexxa laufen soll, und dieses runtimedir dann auf .../user/1001 wechseln muss.

Bei Xubuntu 22.04 wurde aber m.W. nicht standardmäßig Wayland installiert, aber das ist jetzt doch eine Weile her - vielleicht erinnere ich mich da falsch.

Was in der Tat der Fall ist, ist, dass die Crondjobs, die vom System verwendet werden, intern prüfen, ob Systemd da ist, und sich dann, vertrauend darauf, dass die Systemd-Timer das erledigen, verabschieden. Beispiel man-db in /etc/cron.daily:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

#!/bin/sh
#
# man-db cron daily

set -e

if [ -d /run/systemd/system ]; then
    # Skip in favour of systemd timer.
    exit 0
fi
# ...

Aber wenn man nicht selbst seinen cronjob terminiert, wird er ausgeführt, insbesondere gilt das für User-cronjobs, von denen wir hier ja reden.