Hallo,

ich habe ein Shellskript, das regelmäßig als CronJob aufgerufen wird und untersucht, ob ein bestimmtes Programm noch läuft. Ist dies nicht der Fall, wird der Rechner neu gestartet.
Vor dem Neustart sollte der Benutzer allerdings informiert werden, um ihm u.a. die Möglichkeit zu geben den Shutdown abzubrechen. Als GUI wird GNOME verwendet.

Ist es möglich eine Messagebox oder irgendwie einen anderen Hinweis auf dem Desktop auszugeben?
Ich glaube, bei SuSE kam immer eine Nachricht auf dem Desktop (KDE), wenn der Rechner heruntergefahren wurde.

Vielen Dank

Steffen

Hi!

Für den Dialog selbst würde ich zenity verwenden, das ist für den Zweck ideal. Eine ausführliche Einführung in Zenity findest Du, wenn Du im Hilfebrowser Yelp nach Zenity suchst.

Womit ich allerdings immer Probleme hatte, ist, aus einem Cronjob heraus eine Verbindung zum X-Server zu bekommen, um solche Dialoge dann auch anzeigen zu können. Vielleicht hat hier ja jemand einen guten Tipp, wie man das realisieren könnte, das würde mich auch sehr interessieren.

Liebe Grüße
Fredo

Mit zenity kannst du eine Messagebox ausgeben.

zenity --warning --title="Shutdown" --text="Der PC wird jetzt heruntergefahren."

Zenity

Wow, Windows Lösungen unter GNU/Linux.

Läuft etwas nicht dann Rechner neu booten. Geht es immer noch nicht -> Neuinstallieren.

Nur so als Frage, wenn die Applikation nicht mehr läuft, warum startest sie dann nicht einfach wieder?

lol .. bitte entschuldige diesen post.. aber die idee das system neuzustarten anstelle des dienstes find ich jetzt doch seehr amüsant..

Fredo hat geschrieben:

Womit ich allerdings immer Probleme hatte, ist, aus einem Cronjob heraus eine Verbindung zum X-Server zu bekommen, um solche Dialoge dann auch anzeigen zu können. Vielleicht hat hier ja jemand einen guten Tipp, wie man das realisieren könnte, das würde mich auch sehr interessieren.

häng einfach ein

--display :0

hinten dran.

Eventuell vorher noch

xhost +

ausführen.

Im Wiki zu Cron

Cron

Befindet sich btw auch ein passendes Beispiel

*    *    * * *   DISPLAY=:0. zenity --info --text "Beispiel für das Starten eines Programmes mit GUI"

Tschuess
Christoph

Sid Burn hat geschrieben:

Wow, Windows Lösungen unter GNU/Linux.

Läuft etwas nicht dann Rechner neu booten. Geht es immer noch nicht -> Neuinstallieren.

Nur so als Frage, wenn die Applikation nicht mehr läuft, warum startest sie dann nicht einfach wieder?

Die Idee ist uns natürlich auch schon gekommen. Problem ist aber, dass unter DOSEMU ein DOS-Programm ausgeführt wird. Es ist öfters vorgekommen, dass dieses DOS-Programm nicht mehr lief. Ein Neustart von DOSEMU brachte keinen Erfolg, ein Neustart schon.

Danke für die Hilfe

Steffen

Chrissss hat geschrieben:

Im Wiki zu Cron

Cron

Befindet sich btw auch ein passendes Beispiel

*    *    * * *   DISPLAY=:0. zenity --info --text "Beispiel für das Starten eines Programmes mit GUI"

Das funktioniert leider bei mir nicht… Ich habe ein Skript unter /etc/cron.weekly, das folgende Zeile enthält:

/usr/sbin/sbackupd > /dev/null 2>&1 && DISPLAY=:0. zenity --notification --window-icon="info" --text="Backup erstellt"

Trotzdem bekomme ich per Mail folgende Fehlermeldung:

/etc/cron.weekly/sbackup-monitor:
Xlib: connection to ":0.0" refused by server
Xlib: No protocol specified

This option is not available. Please see --help for all possible usages.

Hat jemand eine Idee?

Liebe Grüße
Fredo

Greift ein Programm über die Xlibs auf das lokale Display zu, übermittelt der Client das „Authentification Cookie“ ($HOME/.Xauthority) an den Server. $HOME ist dabei das Homeverzeichnis des Benutzers, unter dessen UID der Client läuft. Stimmt das Cookie nicht mit dem Cookie des Besitzers des Displays überein, so wird die Verbindung abgelehnt.

Ich denke, dass Problem bei dir ist, dass das Display unter der UID des angemeldeten Benutzers läuft, während der Job als root ausgeführt wird => Die Cookies stimmen natürlich nicht überein.

Mögliche Lösungen:

1. Der Client führt „xhost +“ aus, um jedem den Zugriff zu erlauben. Die Lösung ist nicht zu empfehlen, da du damit Angreifern Tür und Tor öffnest. So kann jeder das Display übernehmen, Keylogger betreiben, Programme manipulieren, etc.

2. Du verwendest „xauth“ um das Cookie des Display-Benutzers an root zu übergeben. Näheres verrät die Manpage von xauth… Diese Lösung öffnet jedem Programm, welches als root läuft, den Zugriff auf dein Display.

3. Am einfachsten wäre imho, zenity mit „sudo -H -u $DISPLAYOWNER“ auszuführen. Sudo verwendet dann das $HOME Verzeichnis des Displaybesitzers, um zenity auszuführen. Dadurch wird auch das Cookie des Displaybesitzers verwendet, die Authentifzierung ist erfolgreich. Die Passwortabfrage. verhinderst du mittels eines zusätzlichen Eintrags in /etc/sudoers.

Ah, Oh, Lunar!
Das klingt profund!

user unknown hat geschrieben:

Ah, Oh, Lunar!
Das klingt profund!

Danke

Hi!

Ich habe es jetzt nach Lunars dritter Methode gemacht, und es hat funktioniert!

Das Skript sieht jetzt so aus:

/usr/sbin/sbackupd > /dev/null 2>&1 && DISPLAY=:0. sudo -H -u username zenity --notification --window-icon="info" --text="Backup erstellt"

(Man muss doch den User direkt angeben, eine Umgebungsvariable wie $DISPLAYOWNER gibt es nicht wirklich, oder?)

In der /etc/sudoers habe ich über „visudo“ die Zugangsberechtigung angepasst:

root    ALL=(ALL) ALL, NOPASSWD: /etc/cron.weekly/sbackup-monitor

Und damit funktioniert es dann auch.

Obwohl ich es etwas umständlich finde, dafür extra einen Eintrag in der sudoers vornehmen zu müssen. Vielleicht wäre xauth doch ein eleganterer Weg? Aber für diese Kleinigkeit war es mir zu Umständlich, mich noch in die Bedienung für xauth einzuarbeiten…

Danke für die Tipps!

Liebe Grüße
Fredo

Fredo hat geschrieben:

(Man muss doch den User direkt angeben, eine Umgebungsvariable wie $DISPLAYOWNER gibt es nicht wirklich, oder?)

Nein, die gibt es nicht … Mit DISPLAYOWNER war auch der User gemeint

Fredo hat geschrieben:

Obwohl ich es etwas umständlich finde, dafür extra einen Eintrag in der sudoers vornehmen zu müssen. Vielleicht wäre xauth doch ein eleganterer Weg?

Eleganter schon, aber eben auch komplizierter

Danke für diesen Thread, hat mir sehr geholfen. Habe ein backup-Skript, das beim Anstecken einer USB-Platte ausgeführt wird. Vorher hatte ich es nicht geschafft zenity in dieses Skript einzubinden. Das klappt jetzt, allerdings auch ohne Änderung in /etc/sudoers (hier dapper drake). Es gab nur noch ein Problem: Wenn in Titel oder Text eines zenity-question-Dialoges ein Umlaut stand, funktionierte es zwar manuell vom Terminal aus gestartet, nicht aber im Betrieb vom System aus gestartet.