Neuer Wiki-Artikel über Desktop-Notifications von System-Services mittels dbus

[scientific]

Hi Leute!

Ich hab einen neuen Artikel über Desktop-Notifications von Hintergrund- und System-Services geschrieben, welche das Problem elegant löst, dass man notify-send für jeden einzelnen eingeloggten User separat mittels sudo oder runuser ausführen muss und zuvor testen ob die Session auch tatsächlich eine graphische Session ist.

Desktop-Notification_von_Systemservice_mittels_dbus

Bitte um Test und Ergänzung/Korrektur.

lg scientific

[smutbert]

Danke
(und schade, dass etwas vergleichbares bei Debian/freedesktop.org/... nicht schon von Haus dabei ist, so muss jeder Dienst seinen eigenen „notification-daemon-Clientdienst“ mitbringen, zum Beispiel apparmor-notify).

[inne]

Code: Alles auswählen

inne@mydebian:~
$ dbus-send Testmessage Body
Must use org.mydomain.Interface.Signal notation, no dot in "Body"
EXIT STATUS: 1
inne@mydebian:~
$ 

Code: Alles auswählen

inne@mydebian:~
$ /usr/local/bin/desktop-notify.py
  File "/usr/local/bin/desktop-notify.py", line 5
    systembus = dbus.SystemBus()|sessionbus = dbus.SessionBus()
SyntaxError: can't assign to operator
EXIT STATUS: 1
inne@mydebian:~
$ 

Mehr konnte ich nicht testen, weil das obige ja schon bei mir nicht funktioniert!

Und was ich auch nicht verstehe ist, das im Kapitel "User-Dienst der Graphischen Session" und "Senden der Message an den Systembus von der Shell" beide Skripte /usr/local/bin/desktop-notify.py als Pfad haben. Sind das nicht zwei verscheide? Einmal der Deamon und einmal das Programm...

[smutbert]

Den ersten Fehler wird man los indem man statt »systembus = dbus.SystemBus()|sessionbus = dbus.SessionBus()«

Code: Alles auswählen

systembus = dbus.SystemBus()
sessionbus = dbus.SessionBus()

schreibt.

Der Client-Teil läuft dann fehlerfrei, aber löst leider noch keine Benachrichtigungen aus. Ich weiß noch nicht was ich hier übersehe (sonst würde ich im Wikiartikel mitmischen).

Dass die Pfade übereinstimmen ist tatsächlich etwas unglücklich.

[inne]

Dass die Pfade übereinstimmen ist tatsächlich etwas unglücklich.

Da kann scientific ja einfach dein "d" an den Namen des Deamon anhängen. Ansonsten wäre es schön den Artikel technisch fehlerfrei zu bekommen, weil das kann man gut brauchen!

Schöne Idee, ich habe da gleich 2mal Verwendung für

[jph]

Hier (Stretch 64 Bit mit GNOME) der gleiche Fehler:

Code: Alles auswählen

jan@x220:~$ dbus-send Testmessage Body
Must use org.mydomain.Interface.Signal notation, no dot in "Body"

Da müsste der Artikel m.E. überarbeitet werden.

Was mir auch nicht ganz klar ist, was der Lauschdienst ist. Ist das „nur“ ein Vehikel, um die Nachricht auf den Bus zu legen?

One more thing: Ich würde mir an deiner Stelle, wenn der Artikel fertig ist, noch mal die Gliederung vornehmen. Aktuell wiederholst du den Namen des Artikels als erste Überschrift und hängst da alle weiteren Überschriften drunter. Ich würde mit einer Einleitung/Zielsetzung des Artikels beginnen (die kann der Leser überfliegen und weiß dann, ob der Artikel für ihn relevant ist) und die Grundlagen und die Umsetzung in gleichgeordneten Folgeabschnitten unterbringen, die du wiederum unterteilen kannst.

[inne]

Den ersten Fehler wird man los indem man statt »systembus = dbus.SystemBus()|sessionbus = dbus.SessionBus()«

Code: Alles auswählen

systembus = dbus.SystemBus()
sessionbus = dbus.SessionBus()

schreibt.

Der Client-Teil läuft dann fehlerfrei, aber löst leider noch keine Benachrichtigungen aus. Ich weiß noch nicht was ich hier übersehe (sonst würde ich im Wikiartikel mitmischen).

Das liegt aber nur noch am letzten Skript aus "Senden der Message an den Systembus aus einem Python3-Programm", denn das " Senden der Message an den Systembus von der Shell" funktioniert dann.der Message an den Systembus von der Shell" funktioniert dann.

Code: Alles auswählen

$ dbus-send --system /my/desktop my.desktop.Notification string:test string:bla

[inne]

Hier (Stretch 64 Bit mit GNOME) der gleiche Fehler:

Code: Alles auswählen

jan@x220:~$ dbus-send Testmessage Body
Must use org.mydomain.Interface.Signal notation, no dot in "Body"

Da müsste der Artikel m.E. überarbeitet werden.

Ist hier vlt. sogar notify-send(1) aus libnotify-bin gemeint und nicht dbus-send?

[habakug]

Ist hier vlt. sogar notify-send(1) aus libnotify-bin gemeint und nicht dbus-send?

Ja. [1]

Gruss, habakug

[1] https://wiki.archlinux.org/index.php/De ... ifications

[smutbert]

[…]
Das liegt aber nur noch am letzten Skript aus "Senden der Message an den Systembus aus einem Python3-Programm", denn das " Senden der Message an den Systembus von der Shell" funktioniert […]

Ja, bis dorthin habe ich den Artikel jetzt inklusive notify-send korrigiert und hoffentlich keine neuen Fehler eingebaut.

[scientific]

Vielen Dank für eure Anmerkungen und Korrekturen.
Ich komm beruflich grad weniger dazu ins Debianforum zu schreiben.

Ich checks nochmal mit meiner Lösung quer, was ich da falsch getippt hab.

Ich mein übrigens schon dbus-send. Das sendet auch an den Systembus und kann vom Serviceskript als root benutzt werden.
Notify-send funzt ja nur innerhalb einer Session eines einzelnen Users.

[smutbert]

[…]
Ich mein übrigens schon dbus-send. Das sendet auch an den Systembus und kann vom Serviceskript als root benutzt werden.
Notify-send funzt ja nur innerhalb einer Session eines einzelnen Users.

Dort wo du es tatsächlich meinst hat es niemand angezweifelt.

Gemeint ist es im Absatz zum Testen ob ein notification-daemon läuft - dort hast du imho schon notify-send gemeint (dort hab ich im Artikel auch dbus-send durch notify-send ersetzt). (Mir ist zuerst nur aufgefallen, dass die Befehlsoptionen nicht zu dbus-send passen, dass sie aber zu notify-send passen ist mir erst aufgefallen, nachdem Inne und Habakug es geschrieben haben).

[scientific]

Ja da hast du recht.
Bin noch nicht ganz bei der Sache...
Etwas später hab ich dann Ruhe und Muse, alles zu lesen und zu überarbeiten.

Lg scientific

[scientific]

Danke
(und schade, dass etwas vergleichbares bei Debian/freedesktop.org/... nicht schon von Haus dabei ist, so muss jeder Dienst seinen eigenen „notification-daemon-Clientdienst“ mitbringen, zum Beispiel apparmor-notify).

na das ist ja ein ganz schön umfangreiches Progrämmchen... Aber ich vermute, der tut auch nix anderes, als etwas auf Systembus schreiben, was dann am Sesseinbus abgefangen wird um es an einen Notification-Daemon weiterzuleiten...

Da ich perl nicht wirklich kann, tut ich mir schwer, das Programm jetzt näher zu analysieren.

lg scientific

[scientific]

Hier (Stretch 64 Bit mit GNOME) der gleiche Fehler:

Code: Alles auswählen

jan@x220:~$ dbus-send Testmessage Body
Must use org.mydomain.Interface.Signal notation, no dot in "Body"

Da müsste der Artikel m.E. überarbeitet werden.

Was mir auch nicht ganz klar ist, was der Lauschdienst ist. Ist das „nur“ ein Vehikel, um die Nachricht auf den Bus zu legen?

One more thing: Ich würde mir an deiner Stelle, wenn der Artikel fertig ist, noch mal die Gliederung vornehmen. Aktuell wiederholst du den Namen des Artikels als erste Überschrift und hängst da alle weiteren Überschriften drunter. Ich würde mit einer Einleitung/Zielsetzung des Artikels beginnen (die kann der Leser überfliegen und weiß dann, ob der Artikel für ihn relevant ist) und die Grundlagen und die Umsetzung in gleichgeordneten Folgeabschnitten unterbringen, die du wiederum unterteilen kannst.

Wie schon korrekt angemerkt und korrigiert (danke @smutbert) ist es notify-send und nicht dbus-send in diesem Falle.

Der "Lauschdienst" tut nix anderes als in einer graphischen Session am Systembus zu lauschen und Messages von dort übersetzen und an den Notification-Daemon dieser Session wiederum über dbus weiterzusenden.
Wie schon in der Einleitung des Artikels erläutert ist das Notwendig, da man von einem Systemdienst aus, der über cron, systemd oder ähnliches als root oder ein anderer User gestartet nicht direkt auf jeden einzelnen Notification-Daemon zugreifen kann - oder nur äußerst umständlich mit dem Auslesen der angemeldeten User, dem suchen der grafischen Sessions dieses Users und dann das Auslesen von Environment-Variablen. Das funktioniert einfach nicht zuverlässig, weil es von der verschiedenen Session- und Loginmanagern abhängt, wie man all diese Werte kriegt.

Daher sendet der Service eine Message an den SystemBus von dbus. Der Lauschdienst in jeder einzelnen Session lauscht am Systembus, ob eine Nachricht an ihn gerichtet kommt und leitet diese dann (ein wenig weiterverarbeitet - das genaue Design hängt vom Anwendungsfall ab) an den Notification-Daemon weiter, der dann die Message am Desktop darstellt.
Dieses Design funktioniert immer, wenn dbus installiert und gestartet ist (Soweit ich weiß, ist das in so gut wie allen modernen Linux-Systemen der Fall) und ein Notification-Daemon in der graphischen Session läuft.

Die Gliederung werd ich mir nochmal genauer zu Gemüte führen. Danke für die Hinweise!

lg scientific

[scientific]

Den ersten Fehler wird man los indem man statt »systembus = dbus.SystemBus()|sessionbus = dbus.SessionBus()«

Code: Alles auswählen

systembus = dbus.SystemBus()
sessionbus = dbus.SessionBus()

schreibt.



Der Client-Teil läuft dann fehlerfrei, aber löst leider noch keine Benachrichtigungen aus. Ich weiß noch nicht was ich hier übersehe (sonst würde ich im Wikiartikel mitmischen).

Hab ich da beim Schreiben des Wiki-Artikels einen Formatierungsfehler gemacht? Mir war anfangs die Syntax des Wiki-Markdowns nicht ganz klar...

Das liegt aber nur noch am letzten Skript aus "Senden der Message an den Systembus aus einem Python3-Programm", denn das " Senden der Message an den Systembus von der Shell" funktioniert dann.der Message an den Systembus von der Shell" funktioniert dann.

Code: Alles auswählen

$ dbus-send --system /my/desktop my.desktop.Notification string:test string:bla

Ich komm jetzt nicht ganz dahinter... Scheinbar hast du deinen Satz zu Tode editiert...
Von der Shell aus kannst du an den Lauschdienst eine Message mit dbus-send schicken, die dann auch vom Notification-Daemon angezeigt wird.
Aus dem Python-Programm heraus aber klappt es nicht?


Ich denke, ich werde den Wiki-Artikel noch vereinfachen. Denn der Teil mit der signatur ist nicht unbedingt notwendig, wenn man ausschließlich Strings schickt.

Dass ich beidemale den selben Dateipfad verwendet habe, liegt daran, dass die Programme bei mir spezifischere Namen haben und an anderer Stelle im Dateisystem liegen, da ich sie per Paket installiere... und dann sind sie mir beim Schreiben des Wikiartikels durcheinander gekommen... Asche auf mein Haupt!!!

Das Python-Programm. welches die Message an den Systembus losschickt ist ja nur ein Beispielprogramm zum Testen. Dieses Codeschnipsel kann an dann in eigene Python-Programme einbauen (wie ich es bei meinem BTRFS-Backup-Programm gemacht habe).
Für einfache Shell-Skripte die von Cron aufgerufen werden ist natürlich dbus-send --system.... vollkommen ausreichend. Aber aus anderen Programmiersprachen sind systemcalls immer heikel, daher verwende ich für Python auch die entsprechenden Bindings.
Wäre fein, wenn Kenner anderer Programmiersprachen auch Codeschnipsel mit den entsprechenden dbus-bindings in den Wiki-Artikel schreiben könnten...

Wenn freedesktop.org sowas nicht liefert, könnt ich ja dieses Beispiel soweit ausbauen, dass es für Debian allgemein interessant und aufgenommen wird
Ich denke, sowas fehlt nämlich wirklich essentiell.

lg scientific

[inne]

Das Python-Programm. welches die Message an den Systembus losschickt ist ja nur ein Beispielprogramm zum Testen. Dieses Codeschnipsel kann an dann in eigene Python-Programme einbauen (wie ich es bei meinem BTRFS-Backup-Programm gemacht habe).

Dennoch sollte auch das desktop-notify.py Beispiel-Skript/Listing mit dem obigen desktop-notifyd.py zusammen funktionieren.
(Ich vermute es muss nur /at/xundeenergie/ at.xundeenergie.mkbackup zu /my/desktop my.desktop.Notification geändert werden.)

Für einfache Shell-Skripte die von Cron aufgerufen werden ist natürlich dbus-send --system.... vollkommen ausreichend.

Richtig. Und schön dass du das mit aufzeigst.

Wäre fein, wenn Kenner anderer Programmiersprachen auch Codeschnipsel mit den entsprechenden dbus-bindings in den Wiki-Artikel schreiben könnten...

Genau daran dachte ich auch schon. Aber meine Skills mit DBus sind weak/whack/k.A.^^

[scientific]

So. Ich hab jetzt nochmal den Artikel überarbeitet.

Ja, du hattest recht, es lag an /at/xundeenergie/... und /my/desktop
Jetzt müsste es funktionieren.

Ich hab den Artikel auch neu gegliedert und die Texte überarbeitet. Leider hat mir jemand in der Zwischenzeit während ich schrieb etwas ausgebessert, und ich bin noch nicht so fix im Wiki, dass ich jetzt wüsste, was geändert wurde. Ich hab als letztgültige Version das gespeichert, was ich verfasst habe. Sorry!

Klappt es jetzt?

lg scientific

[inne]

Leider Nein.

ohne Erkennung der Variablentypen in der Message

Code: Alles auswählen

$ /usr/local/bin/desktop-notify.py 
Traceback (most recent call last):
  File "/usr/local/bin/desktop-notify.py", line 22, in <module>
    notify.send_signal('a', 'b')
  File "/usr/local/bin/desktop-notify.py", line 17, in send_signal
    message.append(signature=signature, *msg)
NameError: name 'signature' is not defined
EXIT STATUS: 1
inne@mydebian:~
$ 

Und nimmt man die Zeile "message.append(signature=none, *msg)" raus, dann gibt /usr/local/bin/desktop-notifyd.py aus:

Code: Alles auswählen

inne@mydebian:~
$ /usr/local/bin/desktop-notifyd.py 
Gtk-Message: Failed to load module "canberra-gtk-module"
ERROR:dbus.connection:Exception in handler for D-Bus signal:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 230, in maybe_handle_message
    self._handler(*args, **kwargs)
  File "/usr/local/bin/desktop-notifyd.py", line 16, in notify_updates
    notifications.Notify("Backup finished", 0, icon, "%s-Backup" % (str(args[0])), str(' '.join(args[1:])), "", {}, 0)
IndexError: tuple index out of range

[inne]

.

[scientific]

Leider Nein.

ohne Erkennung der Variablentypen in der Message

Code: Alles auswählen

$ /usr/local/bin/desktop-notify.py 
Traceback (most recent call last):
  File "/usr/local/bin/desktop-notify.py", line 22, in <module>
    notify.send_signal('a', 'b')
  File "/usr/local/bin/desktop-notify.py", line 17, in send_signal
    message.append(signature=signature, *msg)
NameError: name 'signature' is not defined
EXIT STATUS: 1
inne@mydebian:~
$ 

Und nimmt man die Zeile "message.append(signature=none, *msg)" raus, dann gibt /usr/local/bin/desktop-notifyd.py aus:

Code: Alles auswählen

inne@mydebian:~
$ /usr/local/bin/desktop-notifyd.py 
Gtk-Message: Failed to load module "canberra-gtk-module"
ERROR:dbus.connection:Exception in handler for D-Bus signal:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/dbus/connection.py", line 230, in maybe_handle_message
    self._handler(*args, **kwargs)
  File "/usr/local/bin/desktop-notifyd.py", line 16, in notify_updates
    notifications.Notify("Backup finished", 0, icon, "%s-Backup" % (str(args[0])), str(' '.join(args[1:])), "", {}, 0)
IndexError: tuple index out of range

Ah ja klar. Die signatur ist beim Beispiel ohne signatur natürlich nicht definiert. Ich hab das Beispiel angepasst.

[scientific]

Habs jetzt bei mir mit den Beispielen aus dem Wiki nachgestellt, und es funktioniert einwandfrei.

lg scientific

[scientific]

In welche Kategorie würdet ihr denn den Artikel einordnen?
Serverbetrieb? Graphische Oberflächen? Gehört eigentlich in beide...

Oder?

[jph]

Grafische Oberfläche, weil die Benachrichtigungen dort angezeigt werden.

[scientific]

Hab den Wikiartikel noch um einen Link zu meinem Github-Repo ergänzt, wo ich ein fixfertiges Debian-Paket für den Lauschdienst samt xdg-autostart-Eintrag und Testimplementation in python für das Senden einer Testmessage anbiete.

lg scientific