MiniTutorial DBUS was, wieso, wozu

Hinweis: In dem Thema MiniTutorial DBUS was, wieso, wozu gibt es 5 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.
  • MiniTutorial DBUS was, wieso, wozu

    DBUS ist die moderne IPC (InterProcessCommunication). Dieser DatenBUS kennt prinzipiell zwei Modi: einmal "System" und einmal "User". So ziemlich alle modernen Programme können darüber gesteuert werden.

    Das funktioniert über einen Unixsocket. Sockets sind die prinzipielle Methode, wie Programme kommunizieren können. Sie sind ja voneinander ziemlich abgeschottet durch Rechte, verschiedene User usw. Ein Unixsocket ist fast gleich, wie ein Netzwerksocket, außer, dass er keinen Netzwerkteil und somit etwas mehr Overhead bräuchte. Unixsockets sind daher etwas schneller, als z.B. TCP- Sockets.
    Adressiert werden diese Sockets auch mit der UNC (UniversalNamingConvention).
    Ein sehr einfacher Fall als Beispiel: unix://var/run/meinPrivaterSocket.sock Man kann sie überall erstellen. Es ist schlicht eine Gerätedatei. (siehe man mknod; tatsächlich werden intern eher solche UNCs verwendet unix:abstract=/var/run/meinPrivaterSocket.sock,guid=a1b2f3... )

    Wenn das System bootet, wird der dbus-daemon gestartet. Startet dann ein Programm, das via DBUS kommunizieren möchte, so registriert es sich bei diesem Daemon. Ab jetzt kann es an andere Programme oder an das "System" Meldungen oder Befehle senden, oder Nachrichten und Befehle von anderen Programmen entgegennehmen. Ein ps ax -o cmd | grep -i dbus zeigt alle laufenden Instanzen.


    openSUSE (und jede andere Distri auch) bringt dazu einige Programme mit. Für die Konsole gibt es davon einige. Man gebe in einer Konsole schlicht dbus<tab><tab> ein und wundere sich.
    Mit einem schlichten qdbus (QueryDBUS) erhält man:

    Shell-Script

    1. looser@bitschleuder:~>dbus
    2. :1.165
    3. :1.166
    4. :1.167
    5. org.kde.internal.KSettingsWidget_kwincompositing
    6. org.kde.systemsettings5
    7. :1.17
    8. org.kde.baloo
    9. :1.175



    (Die Liste ist natürlich sehr, sehr stark gekürzt)
    Dabei stellen die Zeilen, die mit Doppelpunkt beginnen und dann nur Zahlen und Punkte haben DBUS Instanzen dar, die vom User nicht verwendet werden können. Sie sind entweder dem System vorbehalten, oder dienen speziellen "Informationsaustauschkanäle" zwischen zwei festgelegten Programmen. Zeilen, wie org.kde.systemsettings haben "öffentliche" Interfaces.
    Man sieht hier gut, dass ich die KDE Plasma "Systemsettings" geöffnet habe (org.kde.systemsettings5) und dass ich dort das Rendering (Systemeinstellungen/Hardware/Anzeige und Monitor/Compositor) anzeigen lasse.

    Es gibt neben den dbus* und qdbus Programmen auch noch qdbusviewer, was ein GUI-Programm ist, damit man sich alle DBUS-Teile bequem ansehen kann.

    Und es gibt noch einen Wrapper für qdbus, der es einfach ermöglicht sich mit dem "Notifier" im Systemtray sich Meldungen anzeigen zu lassen:

    Shell-Script

    1. # Einfache Benachrichtigung aus der Konsole
    2. # Beachte das Quoting!
    3. # 'Hello $USER, bla, bla, bla' oder "Hello $User, bla, bla,"
    4. # und EIN zweiter String für die eigentliche Meldung
    5. # 'Juhu....' oder "Juhu, ....."
    6. notify-send -u critical 'Hallo $USER!' 'Juhu!! Es spricht mit mich!!.' --icon=dialog-warning
    Leider kommen bei openSUSE alle diese Programme ohne manpage. Es ist also ziemlich schwierig sich da durchzukämpfen. Verwirrend ist auch, dass man z.B. mit qdbusviewer manche Teile sowohl im Session (=User) -Teil, wie auch im System-Teil findet.
    Noch dazu kann sich das alles mal schnell wieder ändern. Etwas schwierig.

    Ein Beispiel, wie man sich in der Konsole durchhangelt:

    Shell-Script

    1. # erst mal die Konsole finden
    2. qdbus | grep -i Konsole
    3. # OK. Das Interface heißt org.kde.konsole
    4. # wir gucken da rein:
    5. qdbus org.kde.konsole
    6. # boah, ist das viel. Also mal langsam
    7. qdbus org.kde.konsole | less
    8. # wir wissen ja längst, dass wir die Session wollen.
    9. qdbus org.kde.konsole | grep -i Session
    10. # AHA! es heißt /Sessions
    11. # Die Session/<zahl> stellen die einzelnen Tabs dar,
    12. # in denen eine Bash läuft. Sie werden einfach durchnummeriert,
    13. # unabhängig davon, in welchem Konsolenfenster sie laufen. Hat man
    14. # zwei Fenster mit einmal zwei und einmal drei Tabs, so finden sich
    15. # /Sessions/1 bis /Session5 Immer schön der (zeitlichen) Reihe nach.
    16. # wir gucken in das zuallererst geöffnete Tab:
    17. qdbus org.kde.konsole /Sessions/1
    18. # boah. Mal langsam
    19. qdbus org.kde.konsole /Sessions/1 | less
    20. # eigentlich wollen wir nur die Methoden.
    21. qdbus org.kde.konsole /Sessions/1 | grep -i Method
    22. # Die Methoden werden in C- Syntax ausgegeben.
    23. # Aufgerufen werden sie, wie in einer Shell üblich.
    24. # Unser geschultes Auge fiel natürlich sofort auf
    25. qdbus org.kde.konsole /Sessions/1 sendText 'echo hallo\n'
    26. #Boah ey.
    Alles anzeigen
    Ein verrücktes Beispiel, in dem das Ergebnis vor dem Ereignis stattzufinden scheint.
    Wir haben den Befehl echo hallo mit einfachen Apostrophen gequotet, was bewirkt, dass das Newline (entspricht dem Returntaste-Drücken) nicht von der Bash und dem System verschluckt werden kann. Es landet also tatsächlich als Text mit in dem Konsolenfenstertab. Dort wird die Zeichenkette erst mal mit der normalen "Keyboardechofunktion" wiederholt; der Text erscheint also samt dem \n, aber es erfolgt keine Ausführung. Nach der Ausführung des qdbus- Befehls wird, wie üblich der Prompt ausgegeben und dann erscheint, die mittels DBUS simulierte Eingabe. Mit dem eigentlich als "Ausführen!" gedachten \n. So wird das nix.

    Aber das Prinzip sollte klar sein. Und jetzt kann jeder munter Interfaces suchen und dort irgendwelche Methoden ausprobieren. Viele davon sind sogar ganz nützlich, falls man sie findet.

    So kann man alle möglichen Programme fernsteuern. Auch z.B. den "Bildschirmschoner", der manchem in ein Flashvideo spuckt. Der Flashplayer kennt kein DBUS. Aber man kann dem Bildschirmschoner mitteilen, dass er solange ein Flashplayer am Werk ist, nicht aktiv wird.
    Man lese dazu einen Artikel im Linuxjournal

    Auch der Befehl env | grep -i dbus gibt Aufschluss über die Art, wie das funktioniert.

    Shell-Script

    1. # Konsolenprogramme verwenden ENVironment Variablen.
    2. looser@bitschleuder:~> env | grep -i dbus
    3. KONSOLE_DBUS_SERVICE=:1.31
    4. KONSOLE_DBUS_SESSION=/Sessions/1
    5. DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-ytTg5RPqmb,guid=54ac5bc4c121113072c11b7a5851821e
    Das sagt uns, dass die Konsole intern und unzugänglich mit der "Dbus-System-Instanz" via :1.31 kommuniziert. Die KONSOLE_DBUS_SESSION=/Session/1 ist uns jetzt klar. Und die tatsächliche Socket-Bus-Adresse verstehen wir jetzt auch.
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 102007 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • Ich weiß halbwegs wie Linux funktioniert.
    Meine Systeme kann ich auch einigermaßen gut "administrieren".
    Meinen Freunden kann ich Linux (OS) installieren und einrichten.

    Und ich kenne einige Leute (Freunde), die sich im Getriebe von Linux auskennen.

    Deshalb bin ich hier.

    @Berichtigung, denke ja nicht, ich hätte alles verstanden.

    Ich denke, "alles".... Es ist besser ich lasse es,
    und mache das, wovon ich etwas verstehe.

    @Berichtigung, ich weiß, daß Du jünger bist wie ich.
    Du mußt der Gemeinschaft Dein Wissen noch länger weitergeben als ich.

    Das ist keine Bitte, Das ist ein Befehl!!!

    Für den Inhalt des Beitrages 102014 haftet ausdrücklich der jeweilige Autor: Kanonentux

  • Tja, denn werde ich künftig schweigen.
    Als alter Kriegsdienstverweigerer verweigere ich jedweden Befehl.

    Ja, ich stamme aus dieser Zeit, als man noch verweigern musste.
    Als es aktuell wurde, konnte man nach einer Änderung des Gesetzes per Postkarte einfach verweigern.
    Das tat ich natürlich, und auch klar: nicht alleine.

    Nach zwei Wochen war die Änderung wieder eingestampft, weil die Briefkästen einfach nicht groß genug waren.
    Ich zog daher per Einschreiben mit Rückschein meine Verweigerung zurück mit der Begründung,
    dass ich auch gerne ein staatlich geprüftes Gewissen hätte.
    Sie waren stinkesauer, und die folgende Gewissensprüfung fand in aller Härte mehrmals statt.
    Bei der letzten Prüfung marschierte ich mit der stockwerkerschütternden Ansage "Ich habe ihnen diesen Schwachsinn schon viermal erklärt. Wenn sie das nicht kapieren, dann lesen sie ihre Akten zu Hause solange nach bis sie es verstehen, oder lassen sie es sich erklären!" hinaus und schloss die Türe putzrieselnd und nicht weniger laut.

    Ich bin also wirklich sehr renitent.
    Ich verweigere sogar Verweigerungen.
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 102017 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • Ich meint doch nicht einen Befehl eines Militärs, sondern eines deutschen Schutzen.
    Schützen haben sich schon vor 900 Jahren für die Freiheit der Gedanken eingesezt.
    Und Software sind Gedanken der letzten 100 Jahre, es kann sogar noch etwas mehr
    sein. Denn die Idee "mechanischer Rechner" ist einiges älter.

    Was kommt nach:

    Für freie Software und gegen secure boot!
    kanonentux.de/opensuseforum/DSCF4991.AVI

    Für den Inhalt des Beitrages 102026 haftet ausdrücklich der jeweilige Autor: Kanonentux

  • Vielen Dank, das du dir die Mühe gemacht hast alles so gut zu erläutern (auch wenn ich mir nicht ganz sicher bin das ich alles verstanden habe, so habe ich jetzt zumindest eine Idee von DBUS)
    Bitte mehr von solchen Tutorials!

    Für den Inhalt des Beitrages 102034 haftet ausdrücklich der jeweilige Autor: T0lpan

www.cyberport.de