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:
looser@bitschleuder:~>dbus
:1.165
:1.166
:1.167
org.kde.internal.KSettingsWidget_kwincompositing
org.kde.systemsettings5
:1.17
org.kde.baloo
: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:
# Einfache Benachrichtigung aus der Konsole
# Beachte das Quoting!
# 'Hello $USER, bla, bla, bla' oder "Hello $User, bla, bla,"
# und EIN zweiter String für die eigentliche Meldung
# 'Juhu....' oder "Juhu, ....."
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:
# erst mal die Konsole finden
qdbus | grep -i Konsole
# OK. Das Interface heißt org.kde.konsole
# wir gucken da rein:
qdbus org.kde.konsole
# boah, ist das viel. Also mal langsam
qdbus org.kde.konsole | less
# wir wissen ja längst, dass wir die Session wollen.
qdbus org.kde.konsole | grep -i Session
# AHA! es heißt /Sessions
# Die Session/<zahl> stellen die einzelnen Tabs dar,
# in denen eine Bash läuft. Sie werden einfach durchnummeriert,
# unabhängig davon, in welchem Konsolenfenster sie laufen. Hat man
# zwei Fenster mit einmal zwei und einmal drei Tabs, so finden sich
# /Sessions/1 bis /Session5 Immer schön der (zeitlichen) Reihe nach.
# wir gucken in das zuallererst geöffnete Tab:
qdbus org.kde.konsole /Sessions/1
# boah. Mal langsam
qdbus org.kde.konsole /Sessions/1 | less
# eigentlich wollen wir nur die Methoden.
qdbus org.kde.konsole /Sessions/1 | grep -i Method
# Die Methoden werden in C- Syntax ausgegeben.
# Aufgerufen werden sie, wie in einer Shell üblich.
# Unser geschultes Auge fiel natürlich sofort auf
qdbus org.kde.konsole /Sessions/1 sendText 'echo hallo\n'
#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.
# Konsolenprogramme verwenden ENVironment Variablen.
looser@bitschleuder:~> env | grep -i dbus
KONSOLE_DBUS_SERVICE=:1.31
KONSOLE_DBUS_SESSION=/Sessions/1
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.