udev & D-Bus & HAL helyett DeviceKit helyett udisks+UPower - 1. rész: D-Bus

Akit ezzel nem sikerült eltántorítanom, az viszont nyugodtan továbbolvashatja. Arról van ugyanis szó, hogy a címben szereplő téma már régóta érdekelt, de nem volt időm foglalkozni vele. Az utóbbi egy-két hétben azonban rászántam magam, és nem kevés alvásmegvonás árán sikerült megértenem, miről is van itt nagyba' (nem kicsibe, nagyba') szó. Egy rövid sorozat keretében megpróbálom tömören kifejteni. A sorozat minden részét úgy javaslom elolvasni, hogy először fussuk át a szöveget a hivatkozások megnyitása nélkül, és ha ez alapján sikerült nagyjából megérteni, miről van szó, és eldönteni, hogy érdemes-e többet foglalkozni a témával, csak akkor menjünk végig a hivatkozásokon, amelyekből - reményeim szerint - alaposan megismerhetjük a bejegyzés tárgyát.

A D-Bus és kapcsolódó technológiáinak tanulmányozása közben először is szomorúan szembesültem vele, hogy már nincs is HAL, hanem DeviceKit van helyette. Mire megbékéltem volna az elkeserítő ténnyel, kiderült, hogy DeviceKit sincs már, hanem udisks és UPower van helyette. A legnagyobb sokk azonban akkor ért, amikor megtudtam, hogy az udev démon immár nem hoz létre eszközfájlokat, sőt át sem nevezheti azokat. Legutóbb pedig az sokkolt, hogy az udisks és az UPower mellett tovább bővült a HAL-t kiváltó szoftverek köre.

Rántsuk hát le a leplet a tényekről. Legyen szó először a rendszer gerincéről, a D-Bus interprocessz-kommunikációs eszközről:

A sorozat részei: 1 2 3 4

1. D-Bus

Sokan hallottak már a D-Bus-ról, de valószínűleg kevesen tudják, mi is az pontosan. Nem csoda, hiszen általában feltűnés nélkül teszi a dolgát. Mivel minden modern Linux disztribúcióban jelen van, sőt mára már a Linux, és más UNIX jellegű, sőt nem UNIX rendszerek (különösen a desktopon futó változatok) egyik legalapvetőbb technológiája, és az ismerete a rendszergazdák számára - ha más hasznát nem is látjuk ;-) - lehetővé tesz néhány olyan rendkívül hasznos trükköt, amire nem is gondolnánk, az alkalmazásfejlesztők számára pedig egyszerűen KÖTELEZŐ az ismerete, úgy gondoltam, vázlatosan közzéteszem azt, amit sikerült megtudnom róla. Miért ilyen fontos a D-Bus? Mit csinál? D-Bus alapú technológiát teszik lehetővé többek között azt, hogy közönséges felhasználóként a kedvenc asztali környezetünkbe bejelentkezve olyan feladatokat hajtsunk végre, amiket a kernel csak a root felasználónak engedne meg. Felmountolunk egy USB meghajtót? NetworkManagerrel konfiguráljuk a WiFi-t, a 3G internetet vagy bármilyen más hálózati csatolót, és kapcsolódunk egy hálózathoz? Figyelmeztetést kapunk a rendszertől, hogy új szoftverfrissítések érkeztek, majd telepítjük ezeket? Hibernáljuk, felfüggesztjük a gépet? A legtöbb esetben ma már D-Bus alapú technológiát használunk ilyen esetben. A D-Bus lehetővé teszi, hogy egymástól függetlenül, jellemzően más UID alatt indított szoftverösszetevők szabványos és biztonságos módon igénybe vegyék egymás szolgáltatásait. Ha majd lesz (vagy már van?) a Linuxhoz professzionális desktop tűzfal vagy vírusirtó megoldás, a dolgok jelenlegi állasa szerint annak is D-Bus technológiát kell használnia! A D-Bus technológia legfontosabb ihletője a KDE DCOP rendszere volt, és mára a D-Bus leváltotta a DCOP-ot, csakúgy, mint a Gnome Bonobo technológiáját.

A D-Bus FAQ szerint D-Bus egy interprocessz-kommunikációs protokoll, és annak referenciamegvalósítása. Ezen referenciamegvalósítás egyik összetevője, a libdbus könyvtár a D-Bus szabványnak megfelelő kommunikáció megvalósítását segíti. Egy másik összetevő, a dbus-daemon a D-Bus üzenetek routolásáért, szórásáért felelős. A dbus-daemon nélkül is folytathat egymással két partner D-Bus kommunikációt, de nem jellemző ez az elrendezés. A D-Bus protokoll gyakorlatilag komponens alapú szolgáltatások megvalósítására és azok felhasználására szolgál. A D-Bus kommunikáció bármely résztvevője lehet egyszerre "szerver" (aki a szoftverkomponenseket/objektumokat rendelkezésre bocsátja) és "kliens" (aki a rendelkezésre bocsátott szolgáltatásokat igénybe veszi) is, de nem igazán jellemző mindkét szerep ugyanazon ügyfél általi egyidejű betöltése.

A D-Bus rendszer szerverként funkcionáló ügyfelei ún. objektumokat bocsátanak a kliens szerepet betöltő partnerek részére. Ezen objektumok viselkedése nagyban hasonlít az objektumorientált programozás tárgyköréből megismert objektumokéra. Bár az objektumok működése C++ fogalmakkal is jól leírható, de rendelkeznek néhány olyan tulajdonsággal, ami inkább a modernebb objektumorientált nyelvekhez (pl. C#) teszi őket hasonlatossá: Az objektumok futásidőben felkutathatóak, szerkezetük lekérdezhető (ez az ún. introspection), stb. Az a tény azonban, hogy az objektumokat nem az őket felhasználó kliens programok hozzák létre, illetve törlik (ld. constructor/destructor), hanem kizárólag a szerver típusú ügyfelek, sőt, nem is a kliensek állapotterében (memóriájában) léteznek, hanem a szerverekében, a már említett komponens alapú rendszerekkel rokonítja őket, nem pedig valamely konkrét programozási nyelvvel. Az D-Bus rendszer által biztosított - az objektumok elérésére szolgáló - stabil ABI és a többféle programnyelvhez (sőt, parancssori eszközökön keresztül még shell szkriptekhez is) rendelkezésre álló API tovább növeli ezt a hasonlóságot.

A D-Bus szerver jellegű ügyfelei fájlrendszer szerű hierarchiában ajánlják ki az objektumaikat, amit az objektumok neve (a D-Bus nevezéktanában path vagy object path) is tükröz: Az objektumnevek az abszolút UNIX elérési útvonalakhoz hasonlóan a "/" karakterrel kezdődnek, és az objektumhierarchia szintjeit szintén a "/" karakter határolja. Példaként említeném meg, hogy a D-Bus démonhoz csatlakozó programok láthatják, hogy maga a dbus-daemon is megjelenik objektumszolgáltatóként, és a D-Bus kommunikáció többi részvevője számára rendelkezésre bocsát többek között egy "/org/freedesktop/DBus" nevű objektumot.

Amint azt a mindenképpen elolvasásra ajánlott D-Bus tutorial kifejti, az alacsony szinten működő libdbus könyvtár csak a D-Bus kommunikációs protokolljának megvalósítására szolgál, az objektumok magasabb szintű kezelésével nem foglalkozik, ezért a D-Bus rendszer szolgáltatásait igénybe vevő alkalmazások más, magasabb szintű könyvtárakat, illetve objektumokat használnak, mint pl. a GObject vagy a QObject. Ezek a magas szintű natív nyelvi objektumok tipikus esetben proxiként viselkedve teszik elérhetővé a D-Bus objektumokat, teljesen elrejtve a kommunikáció részleteit. A D-Bus tehát kétarcú rendszer: a saját fejlesztői, a disztibútorok és rendszergazdák irányában leginkább interprocessz-kommunkációs eszközként mutatja magát, a rá épülő szoftverek fejlesztő viszont komponens alapú szoftverfejlesztői eszközként gondolhatnak rá.

Minden D-Bus objektum tetszőleges számú osztályba tartozhat. A D-Bus nevezéktanában az osztályok neve interface. Azt, hogy egy objektum egy adott osztály tagja, D-Bus nyelven úgy mondjuk, hogy az objektum szolgáltatást biztosít az adott interfészen keresztül. Az interfészek révén az objektumok tagfüggvényekkel (a D-Bus nevezéktanában method, azaz metódus) és adattagokkal (property vagy attribute) is rendelkeznek. Az adattagok elérésére a D-Bus ABI nem biztosít közvetlen hozzáférést, de létezik egy szabványos interfész, amelynek tagfüggvényei lehetővé teszik, hogy lekérdezzük, illetve módosítsuk az adott objektum összes többi interfészének adattagjait.

A D-Bus interfésznevek fordított DNS domainnevekhez hasonló szerkezetűek. Nem kezdődhetnek "." karakterrel, de legalább egy "." karakternek lennie kell bennük. A fenti példában említett "/org/freedesktop/DBus" objektum pl. a következő interfészeket valósítja meg (C++ elnevezéssel élve a következő osztályokba tartozik): "org.freedesktop.DBus" és "org.freedesktop.DBus.Introspectable". Az két interfésznév hierarchikus kapcsolat vagy öröklés benyomását kelti, holott technikailag egymástól teljesen függetlenek. A D-Bus szabványban semmilyen kapcsolat nincs az interfészek (osztályok) között, legfeljebb a magasabb szintű függvénykönyvtárakban jelenik meg ilyesmi.

A D-Bus objektumok interfészei tagokból (member) állnak. A tagok lehetnek metódusok, szignálok vagy adattagok (property). A metódusok és a szignálok argumentumokkal is rendelkeznek (ezek a metódusok esetében a függyvényparaméterek, illetve visszatérési értékek szerepét töltik be). A property-k, amint korábben már említettem nem kezelhetőek közvetlenül D-Bus üzeneteken keresztül, csak közvetetten, egy kifejezetten ezt a célt szolgáló interfész (org.freedesktop.DBus.Properties) metódusainak segítségével. Amennyiben egy objektum valamely osztályának property típusú tagja (azaz adattagja) is van, akkor ennek az objektumnak az "org.freedesktop.DBus.Properties" interfészt is biztosítania kell, ellenkező esetben hozzáférhetetlenek maradnak az adattagok. Az interfészek tagjainak nevei kizárólag a "[A-Z][a-z][0-9]_" karakterekből állhatnak, vagyis az objektumnevektől és az interfésznevektől eltérően nem tartalmazhatnak "/" vagy "." karaktereket, amelyek hierarchikus elnevezéseket tennének lehetővé. A member-nevek tehát egytagúak.

Amint már említettem, a D-Bus egy IPC, azaz interprocessz-kommunikációs eszköz. A D-Bus ABI tulajdonképpen egy Unix Domain Socketekre épülő kommunikációs protokollt definiál. A D-Bus kommunikáció négyféle üzenetből áll: metódus hívás (method_call), metódus visszatérés (method_return), hiba (error), szignál (signal). A method_call és method_return üzenetek a magaszintű programkönyvtárakban jellemzően függvényhívásként, majd a függvény visszatéréseként jelennek meg, az error típusú üzenetek pedig kivételeket generálnak. A szignál üzenetek broadcast jelleggel terjednek, és arra szolgálnak, hogy a szerver jellegű D-Bus ügyfelek eseményekről tájékoztassák a klienseket.

A kötelezően elolvasandó D-Bus specifikáció egyebek mellett részletesen tárgyalja a D-Bus üzenetformátumát. Ebből megtudhatjuk, hogy a D-Bus üzenetek/adatcsomagok fejlécből és törzsből állnak, és sokféle egyszerű és összetett adattípus átvitelére képesek. A fejléc adatmezői többnyire vezérlési és címzési feladatokat látnak el, az üzenettörzs adatmezői pedig a metódushívások és visszatérések, valamint a hibaüzenetek és szignálok argumentumait hordozzák. A D-Bus üzenetekben a C nyelvbeli printf formátumsztringekhez hasonló "type signature"-ök segítségével történik az adatmezők típusainak és értékeinek kódolása. A D-Bus adattípusai közül mindenképpen említésre méltó a "variant" típus, amelynek használata az adott adattípus meghatározásának futási időig történő késleltetését teszi lehetővé, ezáltal segítve a minden egyes híváskor más és más paraméterekkel vagy visszatérési értékekkel rendelkező metódusok vagy szignálok megvalósítását.

Amint fentebb már kifejtettem, az interfésznevek a path-nevekhez hasonlóan többtagúak, az interfészek tagjainak nevei viszont egytagúak. Az interfész és member-nevek a D-Bus üzenetekben ugyan külön adatmezőben utaznak, de számos D-Bus eszköz (pl. később bemutatásra kerülő dbus-send parancssori eszköz) lehetővé teszi az összevonásukat. Ez azt jelenti, hogy pl. az "org.freedesktop.DBus" interfész "ListNames" metódusára az egyszerűség (és az objektumorientált programozásból eredő megszokás miatt) "org.freedesktop.DBus.ListNames" néven hivatkozhatunk. Ez a ListNames metódus egyébként arra szolgál, hogy az adott dbus-daemon példány minden aktív ügyfelét kilistázza.

A D-Bus szabvány definiál néhány szabványos interfészt, amelyeket a legtöbb D-Bus kompatibilis alkalmazás meg is valósít, ezzel megkönnyítve a D-Buson keresztül elérhető objektumok és szolgáltatásaik feltérképezését, kezelését. A szabványos interfészek közé tartozik a feljebb már említett "org.freedesktop.DBus.Properties", amely az objektumok adattagjainak kezelésére szolgál. Nagy jelentősége van az "org.freedesktop.DBus.Introspectable" interfésznek, amely az "Introspect" metódusa string típusú visszatérési értékében XML formátumú leírást ad az adott objektum szerkezetéről, beleértve az objektum interfészeit, az interfészek metódusait, adattagjait (properties) és szignáljait, valamint az objektum gyermekeinek nevét, amelyek az objektumhierarchiában közvetlenül alatta állnak. Ezeknek (és a többi itt nem említett) szabványos interfésznek a részletes leírása megtalálható a D-Bus specifikációjában.

A dbus-daemon saját objektumai és azoknak interfészei (elsősorban a már említett "org.freedesktop.DBus.ListNames" metódusra gondolok itt), valamint a D-Bus ügyfelek saját objektumainak szabványos interfészei (feltéve, hogy tényleg szabványosan vannak megvalósítva!) lehetővé teszik többek között azt, hogy grafikus D-Bus-szolgáltatás feltérképező- és kezelő alkalmazások készüljenek, mint pl. a kdbus vagy a DBusExplorer.

Amint tehát már utaltam rá, a D-Bus kommunikáció Unix Domain Socketeken keresztül történik (ezért mindig egy hoszton belül zajlik, hálózaton keresztül nem lehet átvinni). Miután a D-Bus ügyfél rákapcsolódott a dbus-daemon socketjére, először egy SASL autentikációs folyamaton kell végigmennie. Az autentikáció típusa az általam megfigyelt rendszereken "EXTERNAL" volt (legalábbis a rendszer-dbus esetében), amiről a D-Bus specifikáció autentikációról szóló részének elolvasása után azt gondoltam, hogy a kliens sendmsg vagy hasonló out-of-band módszer segítségével aktívan autentikál. Néhány strace lefuttatása után azonban rájöttem, hogy bár az autentikáció magától értetődően out-of-band módon történik, de a kliensnek nem kell közreműködnie, hanem a dbus-daemon a Linux kernel segítségével saját maga nyomozza ki a kliens kilétét (vagyis UNIX user ID-ját), mégpedig a getsockopt rendszerhívás SO_PEERCRED opcióját segítségül hívva.

A dbus-daemon a sikeres autentikáció után (pontosabban a org.freedesktop.DBus.Hello metódushívásra válaszként) minden hozzá kapcsolódó ügyfélnek kioszt egy automatikusan generált, egyedi címet, ez az ún. "bus name". Az egyedi neveket - még ha az ügyfél lecsatlakozásával fel is szabadulnak - nem osztja ki többé a dbus-daemon. Az egyedi azonosítón kívül minden ügyfél tetszőleges számú nem egyedi vagy jól ismert (well-known) nevet is igényelhet magának. A nem egyedi címek igénylése, karbantartása az - egyébként az "org.freedesktop.DBus" jól ismert címen keresztül elérhető - dbus-daemon /org/freedesktop/DBus objektumának org.freedesktop.DBus interfészébe tartozó metódusok (pl. RequestName, ReleaseName) segítségével történik. Az egyedi és nem egyedi busznevek/címek egyaránt sztring formátumúak. Az egyedi nevek mindig ":" karakterrel kezdődnek, és általában pontokkal elválasztott számokból állnak (pl. ":1.50", ":1.102", ":1.84", stb.). A nem egyedi nevek esetében a címhamisítás elkerülése végett tilos a ":" karakterrel történő kezdés. A jól ismert nevek formátuma jellemzően megegyezik az interfésznevekével, azaz fordított DNS domain alakúak, mint pl.: "org.freedesktop.NetworkManager", "org.freedesktop.ModemManager", "org.freedesktop.Hal"(ami ugyebár időközben elavult, és a legmodernebb disztibúciókban nincs is jelen :-), stb. Észrevehetjük, hogy az egyedi- és jól ismert azonosítók hasonlóképpen viszonyulnak egymáshoz, mint az automatikusan kiosztott IP-címek a DNS nevekhez.

A dbus-daemon legfontosabb feladata a D-Bus üzenetek/adatcsomagok route-olása. Az útválasztás két fejlécmező, a forrás- (sender) és célcím (destination) segítségével történik. Ezekbe a mezőkbe magától értetődően a csomag feladójának, illetve címzettjének egyedi vagy valamelyik nem egyedi (jól ismert) címe kerül. A forráscímet a dbus-daemon tölti ki, így megbízhatónak tekinthető, ezért az esetleges válaszüzenetet küldő ügyfélnek nem kell tartania attól, hogy csomageltérítés történik. Minden D-Bus üzenet rendelkezik sorozatszámmal is, a válaszüzenetek pedig egy külön fejlécmezőben tartalmazzák annak az üzenetnek a sorozatszámát, amire válaszolnak. Ez a mechanizmus ugyancsak az kommunikáció integritásának megőrzésére szolgál. A kitöltött célcím-mezőt tartalmazó csomagok unicast forgalomirányításban részesülnek, a célcím nélküli csomagokat pedig (a szignálok túlnyomó többsége ilyen) broadcast jelleggel mindenkinek kikézbesíti a dbus-daemon.

A dbus-daemon forgalomirányításában csak unicast és broadcast továbbítási forma létezik, tehát nincs irányított multicast. Ennek ellenére a dbus-daemon nem kézbesíti ki feltétel nélkül mindenkinek a broadcast csomagokat. A D-Bus-ra csatlakozó ügyfeleknek szűrési feltételeket kell a kapcsolatukhoz hozzárendelni ahhoz, hogy fogadhassák a nem kifejezetten nekik címzett (többnyire broadcast) adatcsomagokat. A szűrőfeltételek hozzáadására, törlésére a dbus-daemon által kiajánlott /org/freedesktop/DBus objektum org.freedesktop.DBus interfészének AddMatch és RemoveMatch tagfüggvényei szolgálnak. A D-Bus rendszer finomfelbontású szűrői sokrétű képességekkel rendelkeznek a beérkező broadcast üzenetek körének szűkítése tekintetében, azonban ezen felül alkalmasak arra is, hogy megkérjék a dbus-daemont más címzettnek szóló unicast adatcsomagok kikézbesítésére, azaz a D-Bus forgalom lehallgatására. A lehallgatásra szolgáló szűrők (vagy forgalomirányíto szabályok, ha úgy tetszik) mindössze annyiban különböznek a broadcast forgalom megrostálására szolgáló közönséges szürőfeltételektől, hogy az "eavesdrop" nevő flag nem false, hanem true értéket vesz fel bennük.

Az, hogy a dbus-daemon-nal egy eavesdrop flag-et tartalmazó szűrőfeltételt rendeltetünk a D-Bus kapcsolatunkhoz, még nem jelenti azt, hogy a lehallgatni kívánt forgalmat ténylegesen ki fogja tükrözni felénk a démon. Ahhoz, hogy a lehallgatás sikeres legyen, a dbus-daemon konfigurációjában engedélyezni kell az adott csomagok kívánt irányban történő kikézbesítését. A D-Bus konfigurációja ezen a finomfelbontású tűzfal jellegű szűrőfeladaton kívül további biztonsági beállításokat is tartalmaz, pl. korlátozza az egyes ügyfelek által igényelhető és birtokolható nem egyedei azonosítók (bus name) körét, stb. Lehetőség van továbbá arra is, hogy bizonyos azonosítók (jellemzően jól ismert nevek) részére küldött üzenetek aktiválják azt az - esetleg még nem futó - ügyfelet, akihez az azonosító tartozik. Az ilyen inetd jellegűen aktivált ügyfeleket szolgáltatásnak (service) hívjuk a D-Bus nevezéktanban, és működésüket részletesen tárgyalja az imént hivatkozott man oldal.

Egy rendszeren egyidőben tetszőleges számú dbus-daemon példány futhat párhuzamosan. Bármilyen szoftvercsomagnak lehetősége van rá, hogy saját D-Bus példányt indítson testreszabott konfigurációval, hogy ezzel segítse a saját összetevői közötti kommunikációt, kizárva belőle az illetékteleneket. Általában két jól ismert D-Bus példány van jelen egy tipikus Linux rendszerben. A legfontosabb a rendszer "system" dbus-daemon. Ez teszi lehetővé a bevezetőben említett modern desktop technológiák működését, mint pl. a NetworkManager, vagyis ezt közvetít az asztali környezet és a rendszerszolgáltatások között. Események érkeznek rajta keresztül az asztali környezet számára a rendszer- és hardverváltozásokról, mint pl. az akkumulátor töltöttségének változása, a tápkábel kihúzása és bedugása, új WiFi SSID-k megjelenése, térerőváltozások, új USB meghajtó csatlakozása, stb., majd - ha a házirendek (ld. PolicyKit és ConsoleKit/systemd-logind a későbbiekben) lehetővé teszik - a rendszerszolgáltatások végrehajtják a felhasználótól a D-Bus-on keresztül érkező utasításokat. A rendszer D-Bus mellett a nehézsúlyú asztali környezetek (pl. Gnome, KDE) is indítanak egy-egy dbus-daemon példányt minden munkamenethez (ez az ún. "session" bus), amelyen keresztül az asztali környezet jól integrált összetevői kommunikálnak egymással.

Minden D-Bus példány egy Unix Domain Socketen keresztül hallgatózik, itt fogadja az ügyfelek csatlakozását. A rendszer D-Bus socketje a fájlrendszerben van, és általában a "/var/run/dbus/system_bus_socket" elérési úton található (újabban "/run/dbus/system_bus_socket"). A session D-Bus-ok általában absztrakt címzésű Unix Domain Socketen hallgatóznak. A jól ismert D-Bus példányokról, és a hozzájuk tartozó Unix Domain Socketek felkutatásának módjáról bővebben a D-Bus specifikáció "Well-known Message Bus Instances" fejezetében olvashatunk.

A D-Bus rendszernek kér fontos parancssori eszközét szeretném még röviden bemutatni. Az egyik a dbus-monitor, a másik a dbus-send.

A dbus-monitor segítségével tcpdump-szerűen hallgathatjuk le egy adott D-Bus példány forgalmát. A dbus-monitor természetesen "eavesdrop" flag-gel ellátott szűrőfeltételeket használ, tehát a működéséhez szükség lehet a dbus-daemon konfigurációjának módosítására, hogy ténylegesen jogunk legyen hallgatózni. Ennek érdekében a rendszer D-Bus megfigyelésének elősegítése érdekében hozzunk létre pl. egy /etc/dbus-1/system.d/eavesdrop.conf fájl pl. az alábbi tartalommal:


<!DOCTYPE busconfig PUBLIC
"-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<policy context="default">
<allow send_destination="*" eavesdrop="true"/>
</policy>
<policy user="root">
<allow eavesdrop="true"/>
</policy>
</busconfig>


Ezzel a beállítással mindenfajta üzenetet sikerült lehallgatnom, kivéve a method_return típusúakat, de ezzel másnak is problémája akadt, egy programhibából kifolyólag, amit egyes vélemények szerint kijavítottak, más vélemények szerint nem. A dbus-monitor parancs meghívása pl. az alábbi módon történik:

A rendszer D-Bus példány org.freedesktop.PolicyKit1 címen kapcsolatokat fogadó ügyfelének részére küldött metódushívások lehallgatása:
dbus-monitor --system --monitor "type='method_call',destination='org.freedesktop.PolicyKit1'"

A rendszer D-Bus példányon áthaladó összes metódushívás lehallgatása:
dbus-monitor --system --monitor "type='method_call'"

A dbus-send parancs segítségével mi magunk küldhetünk üzenetet tetszőleges D-Bus plédányon keresztül. Néhány egyszerű példa a dbus-send használatára:

A rendszer (system) D-Bus példány ügyfeleinek kilistázása:
dbus-send --system --dest=org.freedesktop.DBus --print-reply --type=method_call /org/freedesktop/DBus org.freedesktop.DBus.ListNames

A rendszer D-Bus org.freedesktop.NetworkManager címen kapcsolatokat fogadó ügyfele (a NetworkManagernek) gyökérobjektumának (jelen esetben /org/freedesktop/NetworkManager) megvizsgálása
dbus-send --system --dest=org.freedesktop.NetworkManager --print-reply --type=method_call /org/freedesktop/NetworkManager org.freedesktop.DBus.Introspectable.Introspect

Hibernálás:
dbus-send --system --dest=org.freedesktop.UPower --print-reply --type=method_call /org/freedesktop/UPower org.freedesktop.UPower.Hibernate

A munkamenet- (session) D-Bus példány ügyfeleinek kilistázása:
dbus-send --session --dest=org.freedesktop.DBus --print-reply --type=method_call /org/freedesktop/DBus org.freedesktop.DBus.ListNames

KDE képernyővédő lezárása:
dbus-send --session --dest=org.kde.screensaver --print-reply --type=method_call /ScreenSaver org.freedesktop.ScreenSaver.Lock

Kmix mester hangerő beállítása 75%-ra (hardver- és hangrendszerfüggő):
dbus-send --session --dest=org.kde.kmix --print-reply --type=method_call /Mixers/0/alsa_output_pci_0000_00_1b_0_analog_stereo org.freedesktop.DBus.Properties.Set string:org.kde.KMix.Control string:volume variant:int32:75

Szerk: Többen is túlságosan bonyolultnak találták a D-Bus rendszert. Erről annyit mindenképpen el kell mondani, hogy a dbus-monitor és dbus-send programok leginkább csak diagnosztikai célokat szolgálnak. A D-Bus éles használata nem parancssorból, hanem bináris programokból történik, megfelelő programkönyvtár-támogatással, tehát valószínűleg nem átlagon felüli módon bonyolult programozási feladat (erről írhatna valaki más). A rendszergazdák, felhasználók feladata szerintem többnyire a rendszer megértésére (ebben kívántam segíteni ezzel a sorozattal), és a második részben bemutatott pklocalauthority jogosultságkezelő rendszer konfigurálására korlátozódik, ami pedig szintén nem túl bonyolult.

A sorozat részei: 1 2 3 4