DBus這個(gè)單詞只要你在Linux桌面上待過一陣子就繞不開它。但不夸張地說很多人用了十年Linux天天在跟它打交道卻始終說不清它到底是個(gè)什么玩意兒。我最早接觸它是因?yàn)閷懽烂嫘」ぞ邥r(shí)要跟系統(tǒng)通知服務(wù)打招呼后來又因?yàn)樵谇度胧皆O(shè)備上排查進(jìn)程通信問題不得不把它的底層機(jī)制徹底啃了一遍。今天就把這筆賬理清楚D-Bus是什么、它解決什么問題、怎么用、以及排坑時(shí)會(huì)遇到哪些經(jīng)典場(chǎng)面。這篇文章適合這樣幾類人看寫Linux桌面應(yīng)用或嵌入式Qt應(yīng)用的開發(fā)者被systemctl、NetworkManager、藍(lán)牙這類服務(wù)背后通信機(jī)制搞暈的運(yùn)維和工程師以及剛接觸Linux進(jìn)程通信、想搞明白這套機(jī)制和socket、共享內(nèi)存有什么不同的新手。我盡量把原理講透同時(shí)把能直接上手的東西都給你。1. 為什么要先聊IPC在回答“DBus是什么”之前得先退一步看看它到底解決什么問題。你可能聽過下面這句話D-Bus是Linux上的進(jìn)程間通信機(jī)制常用于桌面系統(tǒng)和系統(tǒng)服務(wù)之間傳遞消息。這句話本身沒錯(cuò)但太干癟了。真正讓我意識(shí)到它價(jià)值的是這樣一個(gè)場(chǎng)景你桌面上有一個(gè)音樂播放器你按了一下鍵盤上的媒體鍵桌面環(huán)境比如GNOME或KDE要知道這件事還要把它告訴播放器去暫停播放。這里發(fā)生的事就是典型的進(jìn)程間通信IPCInter-Process Communication。兩個(gè)完全獨(dú)立的進(jìn)程誰也不知道對(duì)方長什么樣需要一種機(jī)制來完成一次跨進(jìn)程調(diào)用。Linux下實(shí)現(xiàn)進(jìn)程間通信的手段不少管道、共享內(nèi)存、信號(hào)、Unix域套接字、TCP socket……為什么還要有DBus這個(gè)東西因?yàn)榍懊孢@些方案在面對(duì)“一對(duì)多、動(dòng)態(tài)發(fā)現(xiàn)、基于名字尋址”這類需求時(shí)非常別扭而桌面系統(tǒng)和現(xiàn)代Linux系統(tǒng)服務(wù)恰恰就是這種需求。1.1 進(jìn)程間通信的原始形態(tài)先看看傳統(tǒng)IPC長什么樣。命名管道和Unix域套接字Unix Socket是比較接近D-Bus的實(shí)現(xiàn)方式兩個(gè)進(jìn)程約定一個(gè)固定的路徑比如/tmp/xxx.sock一個(gè)負(fù)責(zé)監(jiān)聽一個(gè)負(fù)責(zé)連接之后在這個(gè)鏈路上收發(fā)字節(jié)流。這種模式在小規(guī)模場(chǎng)景下沒問題但一旦進(jìn)程變多麻煩就來了。你每個(gè)應(yīng)用都得維護(hù)一張“誰在哪個(gè)socket上”的清單而且服務(wù)端和客戶端要約定好消息格式。想象一下系統(tǒng)里有NetworkManager、藍(lán)牙服務(wù)、系統(tǒng)通知、媒體播放器、桌面面板……一共十幾個(gè)服務(wù)每個(gè)服務(wù)都各自開一個(gè)socket客戶端程序得跟十幾個(gè)對(duì)方全部建立起連接還都得處理斷線重連、消息解析、狀態(tài)同步。這套代碼寫出來光是維護(hù)就夠你喝一壺的。共享內(nèi)存則更底層它適合大批量數(shù)據(jù)傳輸?shù)举|(zhì)上不解決誰通知誰、誰調(diào)用誰的問題。信號(hào)signal是最輕量級(jí)的但它只能傳遞一個(gè)編號(hào)傳不了復(fù)雜數(shù)據(jù)結(jié)構(gòu)在應(yīng)用層做RPC遠(yuǎn)程過程調(diào)用完全不夠用。所以你需要一個(gè)“中間人”和一套統(tǒng)一的“對(duì)話規(guī)則”這正是D-Bus的切入點(diǎn)。1.2 DBus相對(duì)傳統(tǒng)IPC的演進(jìn)思路D-Bus的誕生背景是freedesktop.org組織為Linux桌面環(huán)境統(tǒng)一通信協(xié)議而設(shè)計(jì)的時(shí)間大概在2003年前后。它借鑒了當(dāng)時(shí)GNOME的Bonobo和KDE的DCOP兩套機(jī)制的失敗經(jīng)驗(yàn)最終形成了一個(gè)比DCOP更通用、比CORBA更輕量的方案。它做的事情可以概括成四句話提供一個(gè)中央總線central bus所有進(jìn)程都往總線上接互相之間不必直接兩兩連接。用“總線名”代替文件路徑和socket地址實(shí)現(xiàn)進(jìn)程的動(dòng)態(tài)發(fā)現(xiàn)A進(jìn)程不需要事先知道B進(jìn)程的地址。定義了一套二進(jìn)制消息協(xié)議支持方法調(diào)用、信號(hào)廣播、屬性讀寫三類基本操作底層傳輸走Unix域套接字或TCP。自帶服務(wù)激活機(jī)制當(dāng)一個(gè)客戶端請(qǐng)求某個(gè)服務(wù)時(shí)如果該服務(wù)還沒啟動(dòng)總線守護(hù)進(jìn)程可以幫你把它拉起來。這套設(shè)計(jì)讓“誰提供什么服務(wù)”變成一種可查詢、可動(dòng)態(tài)變化的資源而不是寫死在代碼里的連接。DBus等于是在Linux進(jìn)程之間建立了一個(gè)輕量的“軟件總線”設(shè)備、服務(wù)、桌面組件都插在這條總線上交流。2. DBus的整體架構(gòu)與核心概念理解了它要解決的問題再來看架構(gòu)就順多了。D-Bus從上到下分成三層來看底層是傳輸層基于socket的字節(jié)流中間是消息協(xié)議層消息的封裝、序列化、路由最上層是應(yīng)用使用的API綁定層比如GLib的GDBus、Qt的QtDBus、Python的dbus庫以及systemd自己用的sd-bus。實(shí)際在你的Linux系統(tǒng)里跑起來的主要是兩套東西一個(gè)守護(hù)進(jìn)程叫dbus-daemon發(fā)行版里也可能看到dbus-broker這是后來性能更好的替代實(shí)現(xiàn)負(fù)責(zé)維護(hù)總線、轉(zhuǎn)發(fā)消息、管理服務(wù)激活另一套是各個(gè)應(yīng)用鏈接的libdbus庫或者更上層的語言綁定。很多后端服務(wù)比如NetworkManager、systemd、藍(lán)牙服務(wù)bluez、UDisks2都注冊(cè)在總線上供外部調(diào)用。2.1 總線守護(hù)進(jìn)程是核心dbus-daemon是一個(gè)獨(dú)立的進(jìn)程你通過ps aux | grep dbus應(yīng)該能看到它。它負(fù)責(zé)收發(fā)和轉(zhuǎn)發(fā)所有的總線消息。它的工作方式可以用“郵局”來類比每個(gè)進(jìn)程在總線上注冊(cè)時(shí)相當(dāng)于郵局給它分配了一個(gè)郵箱一個(gè)唯一的連接名進(jìn)程想給別的進(jìn)程發(fā)消息就把消息投遞到郵局由郵局按地址送到對(duì)方郵箱。這里有個(gè)關(guān)鍵點(diǎn)通信雙方之間并不直接建立P2P連接消息總是經(jīng)過守護(hù)進(jìn)程轉(zhuǎn)發(fā)。這樣做的代價(jià)是多了一次轉(zhuǎn)發(fā)延遲消息從發(fā)送進(jìn)程到守護(hù)進(jìn)程再從守護(hù)進(jìn)程到接收進(jìn)程兩次unix socket讀寫但換來的是全系統(tǒng)的統(tǒng)一尋址、權(quán)限控制和狀態(tài)管理。這在一個(gè)進(jìn)程幾十個(gè)的桌面環(huán)境里是絕對(duì)劃算的。dbus-daemon的配置文件通常在這些位置/usr/share/dbus-1/system.conf系統(tǒng)總線/usr/share/dbus-1/session.conf會(huì)話總線/etc/dbus-1/system.d/系統(tǒng)服務(wù)安全策略/usr/share/dbus-1/system.d/發(fā)行版自帶服務(wù)策略/usr/share/dbus-1/services/session bus服務(wù)激活文件/usr/share/dbus-1/system-services/system bus服務(wù)激活文件2.2 連接的端點(diǎn)、地址與名字D-Bus里面最重要的是“名字”。所有連接到總線上的進(jìn)程都至少有一個(gè)地址標(biāo)識(shí)主要有三類總線地址Bus Address實(shí)際連接的物理位置是一個(gè)類似unix:path/run/dbus/system_bus_socket的字符串。它相當(dāng)于普通socket的地址通常在進(jìn)程連接總線時(shí)使用日常開發(fā)中很少直接涉及。唯一連接名Unique Connection Name進(jìn)程連接總線成功后守護(hù)進(jìn)程分配的名字形如:1.42。它相當(dāng)于郵局分配的郵箱號(hào)保證唯一。眾所周知的名稱Well-known Name一個(gè)類似反向域名的字符串比如org.freedesktop.NetworkManager、org.bluez。它相當(dāng)于一個(gè)服務(wù)的“固定呼號(hào)”其他進(jìn)程只需要記這個(gè)名字不需要關(guān)心服務(wù)到底用什么唯一名稱。比如你告訴總線“我要發(fā)給org.freedesktop.Notifications”守護(hù)進(jìn)程會(huì)自動(dòng)把消息路由給持有這個(gè)名字的進(jìn)程。好比你打電話不需要知道對(duì)方今天的SIM卡號(hào)只要記住他的固定號(hào)碼。這也是D-Bus能實(shí)現(xiàn)“服務(wù)動(dòng)態(tài)上線、客戶端無需關(guān)心”的核心原因。2.3 消息的格式與信號(hào)傳遞總線上的通信單元是“消息”Message。D-Bus消息分為四種基本類型消息類型作用類比method_call調(diào)用遠(yuǎn)端進(jìn)程的方法“幫我執(zhí)行某個(gè)函數(shù)”method_return返回調(diào)用結(jié)果“這是執(zhí)行結(jié)果”signal廣播一個(gè)事件“我這邊發(fā)生了某某事件”error返回錯(cuò)誤信息“調(diào)用失敗了這是原因”信號(hào)是D-Bus非常出彩的設(shè)計(jì)。它是一對(duì)多的廣播任何進(jìn)程都能向總線發(fā)送一條signal總線會(huì)把它轉(zhuǎn)發(fā)給所有對(duì)該信號(hào)感興趣的進(jìn)程而不需要發(fā)出者知道有哪些進(jìn)程在聽。桌面鎖屏、網(wǎng)絡(luò)狀態(tài)切換、USB設(shè)備插入這些都是靠signal廣播出去的?？蛻舳送ǔＭㄟ^“匹配規(guī)則”match rule訂閱自己關(guān)心的信號(hào)比如只接收org.freedesktop.NetworkManager發(fā)出的狀態(tài)變化。信號(hào)強(qiáng)度被我在實(shí)際項(xiàng)目中反復(fù)驗(yàn)證比如讓兩個(gè)完全不相識(shí)的進(jìn)程做聯(lián)動(dòng)A進(jìn)程廣播一個(gè)“文件導(dǎo)入完成”B進(jìn)程什么都不用知道只要訂閱了這個(gè)信號(hào)就能做出響應(yīng)。你完全繞開了一對(duì)一socket連接那一堆連接管理代碼。2.4 對(duì)象、接口、方法與屬性模型D-Bus之上還不是簡(jiǎn)單的“發(fā)消息”而是一個(gè)RPC風(fēng)格的調(diào)用模型。它約定了一種“對(duì)象路徑 接口 方法/信號(hào)/屬性”的三段式結(jié)構(gòu)。對(duì)象路徑Object Path形如/org/freedesktop/NetworkManager類似URL路徑用來定位服務(wù)內(nèi)部的某個(gè)對(duì)象。注意這里的對(duì)象是邏輯概念服務(wù)端可以用任意語言實(shí)現(xiàn)它。接口Interface形如org.freedesktop.DBus.Properties或org.bluez.Device1聲明了對(duì)象提供哪些方法和信號(hào)。接口名和總線名類似也是反向域名風(fēng)格避免沖突。方法Method、信號(hào)Signal、屬性Property接口里面可以定義這些成員。方法與本地函數(shù)調(diào)用相似只是跨進(jìn)程信號(hào)供外部訂閱屬性代表該對(duì)象的當(dāng)前狀態(tài)可讀或可寫。舉個(gè)例子通過D-Bus讓藍(lán)牙設(shè)備斷開連接你會(huì)看到類似這樣的調(diào)用目標(biāo)總線名org.bluez由藍(lán)牙服務(wù)持有對(duì)象路徑/org/bluez/hci0/dev_XX_XX_XX_XX_XX_XX表示某個(gè)已配對(duì)設(shè)備接口org.bluez.Device1方法Disconnect這套模型把事情整理得非常規(guī)整無論底層是誰在實(shí)現(xiàn)調(diào)用方的代碼結(jié)構(gòu)都是統(tǒng)一的。3. 兩條主干道System Bus與Session Bus你的Linux系統(tǒng)上其實(shí)跑著至少兩個(gè)總線實(shí)例。大多數(shù)人第一次被D-Bus弄暈就是因?yàn)闆]搞清這兩個(gè)東西的分工。3.1 system bus與session bus的分工System Bus是系統(tǒng)級(jí)總線從開機(jī)就運(yùn)行負(fù)責(zé)承載系統(tǒng)服務(wù)之間的通信比如systemd、NetworkManager、UDisks2、藍(lán)牙守護(hù)進(jìn)程都注冊(cè)在這條總線上。它對(duì)應(yīng)socket文件通常在/run/dbus/system_bus_socket并且普通用戶對(duì)它沒有寫權(quán)限——這是有意的安全設(shè)計(jì)。Session Bus是每個(gè)用戶登錄時(shí)啟動(dòng)的會(huì)話總線負(fù)責(zé)承載桌面環(huán)境內(nèi)部各組件的通信。GNOME Shell、文件管理器、通知服務(wù)、剪貼板管理、媒體播放器都在這條總線上聊天。每個(gè)登錄用戶都有自己的session bussocket路徑類似/run/user/1000/bus其中1000是用戶ID。同一個(gè)人登錄兩個(gè)會(huì)話比如本地桌面和SSH里的systemd user實(shí)例就有兩條獨(dú)立的session bus。為什么必須分開如果大家都擠在同一條總線上一個(gè)普通用戶就能給系統(tǒng)服務(wù)發(fā)消息或者監(jiān)聽別人桌面組件的通信。分開之后系統(tǒng)總線上可以施加嚴(yán)格的安全策略session bus只對(duì)當(dāng)前可信的桌面會(huì)話開放。這種分層和物理網(wǎng)絡(luò)里的核心網(wǎng)、接入網(wǎng)分開在邏輯上是一個(gè)道理。3.2 服務(wù)激活機(jī)制D-Bus還有一個(gè)讓人省心的機(jī)制——服務(wù)激活Service Activation。設(shè)想這樣一個(gè)場(chǎng)景你調(diào)用org.freedesktop.Notifications發(fā)通知但這個(gè)服務(wù)還沒啟動(dòng)。傳統(tǒng)socket方案會(huì)直接連接失敗而D-Bus總線發(fā)現(xiàn)這個(gè)well-known name無人持有的話會(huì)去掃描激活文件目錄找到org.freedesktop.Notifications.service這個(gè)文件根據(jù)文件里指定的Exec命令把服務(wù)拉起來等它注冊(cè)到總線上再完成這次調(diào)用。system bus同樣存在激活機(jī)制systemd甚至深度參與其中——很多系統(tǒng)服務(wù)在D-Bus配置文件里通過SystemdService關(guān)聯(lián)到一個(gè)systemd unit。當(dāng)收到D-Bus請(qǐng)求時(shí)dbus-daemon或dbus-broker會(huì)觸發(fā)systemd啟動(dòng)對(duì)應(yīng)的unit。這也是為什么你調(diào)用某個(gè)還沒啟動(dòng)的系統(tǒng)服務(wù)時(shí)服務(wù)的進(jìn)程會(huì)“嗖”地一下出現(xiàn)在進(jìn)程列表里。system bus和systemd之間的這種配合讓“按需啟動(dòng)”成為系統(tǒng)服務(wù)常態(tài)。3.3 傳統(tǒng)桌面為何以Session Bus為主如果你是在寫桌面客戶端絕大部分日常操作都走session bus。比如你的應(yīng)用想監(jiān)聽系統(tǒng)音量調(diào)整、屏幕鎖定、網(wǎng)絡(luò)變化這些信號(hào)大多數(shù)由桌面會(huì)話內(nèi)的專屬組件發(fā)出。而如果應(yīng)用想控制NetworkManager連接Wi-Fi那是調(diào)用system bus上的服務(wù)需要管理員權(quán)限時(shí)再通過polkit一個(gè)D-Bus上的特權(quán)授權(quán)服務(wù)去申請(qǐng)授權(quán)。判斷一個(gè)服務(wù)到底走哪條總線有一個(gè)簡(jiǎn)單經(jīng)驗(yàn)系統(tǒng)級(jí)服務(wù)、需要特權(quán)或者影響整個(gè)系統(tǒng)的走system bus桌面會(huì)話級(jí)、只跟當(dāng)前用戶UI相關(guān)的走session bus。實(shí)際項(xiàng)目里也有跨總線的情況比如桌面面板要讀取網(wǎng)絡(luò)狀態(tài)它會(huì)同時(shí)連接兩條總線分別跟不同的服務(wù)通信。4. 實(shí)操命令行工具與開發(fā)實(shí)踐理論講完直接上手。我建議用最少必要步驟把D-Bus“跑通”建立體感。Linux桌面環(huán)境通常都帶dbus-send和dbus-monitor兩個(gè)命令有些發(fā)行版需要額外安裝dbus-tools包。再配合一個(gè)圖形化工具d-feet做瀏覽基本夠你用很久。4.1 五分鐘體驗(yàn)用dbus-send查詢與調(diào)用先看最基礎(chǔ)的兩個(gè)子命令我強(qiáng)烈建議你親手敲一遍# 列出session bus上所有持有名字的服務(wù) dbus-send --session --destorg.freedesktop.DBus --typemethod_call \ --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames解析一下--destorg.freedesktop.DBus表示發(fā)給總線守護(hù)進(jìn)程本身它也是一個(gè)D-Bus服務(wù)對(duì)象路徑是/org/freedesktop/DBus調(diào)用接口org.freedesktop.DBus上的ListNames方法。返回結(jié)果是一長串字符串列表這些就是當(dāng)前總線上所有服務(wù)名。你會(huì)看到org.freedesktop.Notifications、org.gnome.Shell之類。再試試調(diào)用一個(gè)真實(shí)服務(wù)。以通知為例前提是你桌面有通知服務(wù)dbus-send --session --destorg.freedesktop.Notifications \ --typemethod_call --print-reply \ /org/freedesktop/Notifications \ org.freedesktop.Notifications.Notify \ string:my-app uint32:0 string:dialog-information \ string:Hello from D-Bus string:這是通過D-Bus發(fā)送的通知 \ string:[] dict:string:variant:{} int32:5000這行命令完整演示了帶多個(gè)參數(shù)的調(diào)用應(yīng)用名、替換id、圖標(biāo)名、摘要、正文、動(dòng)作列表、提示參數(shù)、超時(shí)時(shí)間。執(zhí)行之后桌面右上角應(yīng)該會(huì)彈出一條通知。能做到這一點(diǎn)說明你已經(jīng)掌握D-Bus作為RPC的使用方式了。如果要看系統(tǒng)總線上有什么把--session換成--system。注意普通用戶對(duì)system bus很多send操作會(huì)被安全策略攔截所以觀察為主。4.2 用dbus-monitor監(jiān)聽信號(hào)監(jiān)聽信號(hào)是排查問題時(shí)的利器。打開一個(gè)終端dbus-monitor --session然后你去干點(diǎn)別的比如切換一下壁紙、調(diào)整音量、鎖屏再解鎖終端里會(huì)不斷滾動(dòng)出各種method_call和signal消息。初次看到會(huì)覺得這是天書但仔細(xì)看能發(fā)現(xiàn)消息結(jié)構(gòu)跟前面講的對(duì)象路徑、接口、方法一一對(duì)應(yīng)。信號(hào)消息會(huì)有signal字樣和對(duì)應(yīng)的interface/member名。如果想只看特定的服務(wù)可以用match參數(shù)。比如只看NetworkManager的狀態(tài)變化dbus-monitor --system interfaceorg.freedesktop.NetworkManager監(jiān)聽信號(hào)這個(gè)動(dòng)作本身非常有價(jià)值——它能幫你驗(yàn)證“某個(gè)操作到底有沒有在總線上打消息”也是排查D-Bus調(diào)用是否成功的第一手證據(jù)。4.3 用d-feet可視化瀏覽總線終端命令適合快速驗(yàn)證但真要瀏覽整個(gè)總線上有哪些服務(wù)、每個(gè)服務(wù)提供哪些對(duì)象和接口圖形化工具d-feet有的發(fā)行版包名叫d-feet或dfeet是效率最高的。打開之后左邊選System Bus或Session Bus展開某一個(gè)服務(wù)名右側(cè)會(huì)顯示對(duì)象樹點(diǎn)開接口能看到方法和信號(hào)列表雙擊方法可以直接填參數(shù)調(diào)用。這個(gè)工具在我調(diào)試藍(lán)牙服務(wù)的時(shí)候幫了大忙不用翻文檔也能很快搞清楚某個(gè)接口有哪些方法、參數(shù)類型是什么。它等于一個(gè)D-Bus接口的“瀏覽器”。調(diào)試的時(shí)候我習(xí)慣先開d-feet找到服務(wù)提供的方法再用dbus-send在腳本里復(fù)現(xiàn)同樣的調(diào)用。4.4 用Python綁定寫一個(gè)最小調(diào)用如果你要寫代碼我推薦先用Python把鏈路跑通因?yàn)檎Z法最直觀。Linux桌面通常自帶python3-dbus或者python3-gi后者是基于GLib的GDBus綁定功能更全。下面這個(gè)例子用python3-gi調(diào)NetworkManager獲取連接狀態(tài)import gi gi.require_version(Gio, 2.0) from gi.repository import Gio bus Gio.bus_get_sync(Gio.BusType.SYSTEM, None) # 調(diào)用NetworkManager的org.freedesktop.DBus.Properties接口讀取ActiveConnections屬性 result bus.call_sync( Gio.BusType.SYSTEM, # 系統(tǒng)總線 org.freedesktop.NetworkManager, # 目標(biāo)總線名 /org/freedesktop/NetworkManager, # 對(duì)象路徑 org.freedesktop.DBus.Properties, # 接口名 Get, # 方法名Get GLib.Variant((ss), (org.freedesktop.NetworkManager, ActiveConnections)), None, Gio.DBusCallFlags.NONE, -1, None ) if result: print(result)如果你更習(xí)慣用經(jīng)典的dbus-python庫寫法是這樣import dbus bus dbus.SystemBus() # 獲得NetworkManager的代理對(duì)象 nm bus.get_object(org.freedesktop.NetworkManager, /org/freedesktop/NetworkManager) props dbus.Interface(nm, org.freedesktop.DBus.Properties) connections props.Get(org.freedesktop.NetworkManager, ActiveConnections) print(connections)兩者的差別主要是編程模型GDBus偏異步和回調(diào)dbus-python偏同步和對(duì)象代理。小工具用dbus-python夠用大型應(yīng)用建議直接上GDBus它的類型系統(tǒng)更嚴(yán)謹(jǐn)而且跟GLib主循環(huán)天然配合。4.5 用GDBus或QtDBus做正式項(xiàng)目真正落地到項(xiàng)目里語言綁定選擇很重要。C語言項(xiàng)目一般用GDBusGLib自帶或者sd-bussystemd內(nèi)置的C庫。GDBus的好處是類型檢查和文檔齊全sd-bus更輕量性能也更好但它依賴systemd的libsystemd。C/Qt項(xiàng)目首選QtDBus它把QDBusMessage、QDBusInterface封裝得比較自然跟Qt的信號(hào)槽機(jī)制融合得很好。嵌入式場(chǎng)景下如果你自己寫守護(hù)進(jìn)程對(duì)外提供服務(wù)用sd-bus注冊(cè)一個(gè)服務(wù)名的樣板代碼量很小鏈路的穩(wěn)定性也比直接裸寫unix socket高很多。GDBus和sd-bus選型上有一條經(jīng)驗(yàn)項(xiàng)目已經(jīng)依賴GLib就用GDBus項(xiàng)目跟systemd生態(tài)深度綁定就選sd-bus兩邊都不沾就看團(tuán)隊(duì)熟悉度。5. 安全模型與權(quán)限控制D-Bus的安全值得單獨(dú)劃一章說因?yàn)榭邕M(jìn)程通信的本質(zhì)就是跨信任邊界。你通過總線調(diào)用的任意一個(gè)方法都等同于賦予對(duì)方訪問你的數(shù)據(jù)或控制設(shè)備的能力。5.1 安全策略配置誰能調(diào)誰dbus-daemon對(duì)system bus默認(rèn)有較嚴(yán)格的策略。配置文件目錄里每個(gè)服務(wù)對(duì)應(yīng)一個(gè).conf文件。例如一個(gè)典型的系統(tǒng)服務(wù)策略文件長這樣busconfig policy userroot allow ownorg.example.MyService/ allow send_destinationorg.example.MyService/ /policy policy contextdefault deny send_destinationorg.example.MyService/ /policy /busconfig解讀一下own表示誰可以注冊(cè)這個(gè)名字send_destination表示誰可以往這個(gè)服務(wù)發(fā)消息。上面策略的意思是只有root用戶能擁有org.example.MyService這個(gè)名字其他任何人對(duì)它發(fā)消息都被拒絕。如果需要普通用戶也能調(diào)用就得把用戶放進(jìn)某個(gè)group或者主動(dòng)添加一個(gè)allow規(guī)則policy contextdefault allow send_destinationorg.example.MyService/ allow send_destinationorg.example.MyService send_interfaceorg.example.MyInterface/ /policy通常的做法是只放開必要的接口而不是全部接口。比如允許普通用戶調(diào)用查詢方法但拒絕管理方法。這一點(diǎn)我踩過坑早期圖省事全放開了結(jié)果任何本地用戶都能通過D-Bus修改服務(wù)配置日志審計(jì)很難看。所以寫系統(tǒng)服務(wù)時(shí)策略文件的粒度一定要細(xì)化到接口。5.2 特權(quán)操作與polkit很多系統(tǒng)管理操作需要管理員權(quán)限比如連接Wi-Fi、掛載磁盤。D-Bus本身不做授權(quán)生產(chǎn)環(huán)境中這項(xiàng)工作通常交給polkitPolicyKit。流程大致是這樣客戶端調(diào)用NetworkManager的Connect方法NetworkManager收到請(qǐng)求后用polkit的API詢問“這個(gè)調(diào)用者是否有權(quán)限執(zhí)行這個(gè)動(dòng)作”polkit會(huì)根據(jù)調(diào)用者的用戶ID、動(dòng)作ID、活動(dòng)會(huì)話狀態(tài)是否在本地登錄、是否處于活躍會(huì)話做出判定必要時(shí)彈出認(rèn)證對(duì)話框認(rèn)證通過后polkit回復(fù)授權(quán)NetworkManager才繼續(xù)執(zhí)行。所以你看到“插入U(xiǎn)SB后桌面彈出密碼框”本質(zhì)上就是一個(gè)D-Bus調(diào)用觸發(fā)了polkit授權(quán)流程。自己寫系統(tǒng)級(jí)守護(hù)進(jìn)程時(shí)如果包含敏感操作用polkit做授權(quán)比自己在代碼里判斷用戶身份要規(guī)范得多。5.3 兩條總線的安全邊界Session bus默認(rèn)信任當(dāng)前用戶策略通常比較寬松。System bus則嚴(yán)格得多。這種設(shè)計(jì)的風(fēng)險(xiǎn)邊界要心里有數(shù)同一個(gè)用戶的所有進(jìn)程都能訪問同一個(gè)session bus因此session bus上的服務(wù)不應(yīng)該承擔(dān)“隔離敏感數(shù)據(jù)”的任務(wù)。如果兩個(gè)進(jìn)程屬于同一個(gè)用戶但信任等級(jí)不同比如一個(gè)是瀏覽器一個(gè)是你的密碼管理器它們同時(shí)連在session bus上從機(jī)制上講瀏覽器有權(quán)限向密碼管理器發(fā)請(qǐng)求你得靠密碼管理器自己實(shí)現(xiàn)接口級(jí)鑒權(quán)。這也是提醒自己D-Bus的權(quán)限模型只是框架真正決定安全的是服務(wù)實(shí)現(xiàn)里怎么校驗(yàn)請(qǐng)求。6. 常見問題與排查技巧實(shí)錄最后一部分直接上排障經(jīng)驗(yàn)。D-Bus是Linux桌面上最頻繁出問題的“隱形基礎(chǔ)設(shè)施”之一我把這些年遇到的典型問題和排查套路整理成下面的速查表?，F(xiàn)象典型原因排查方法dbus-send提示Error org.freedesktop.DBus.Error.ServiceUnknown目標(biāo)服務(wù)未啟動(dòng)或尚未注冊(cè)名字dbus-send --session --destorg.freedesktop.DBus --typemethod_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames看名字是否存在等待服務(wù)啟動(dòng)后重試dbus-monitor有信號(hào)但應(yīng)用收不到匹配規(guī)則寫錯(cuò)信號(hào)在錯(cuò)誤的總線session/page上檢查match參數(shù)里的interface/member是否準(zhǔn)確確認(rèn)監(jiān)聽的總線與發(fā)出者一致普通用戶調(diào)用system bus服務(wù)被拒system bus安全策略未放行查看/usr/share/dbus-1/system.d下對(duì)應(yīng)服務(wù)的conf文件確認(rèn)send_destination和send_interface規(guī)則桌面環(huán)境啟動(dòng)后dbus-daemon崩潰多個(gè)總線實(shí)例沖突或權(quán)限錯(cuò)誤systemctl --user status dbus.socket或dbus-daemon --session --print-address查看socket路徑檢查/run/user/uid/bus是否存在服務(wù)激活失敗進(jìn)程始終未啟動(dòng).service文件Exec路徑錯(cuò)誤或服務(wù)退出太快手動(dòng)執(zhí)行Exec里的命令看能否正常注冊(cè)到總線觀察journalctl日志調(diào)用方法無響應(yīng)進(jìn)程卡住服務(wù)端主循環(huán)阻塞或死鎖strace -p 服務(wù)進(jìn)程看是否阻塞在特定的fd上確認(rèn)服務(wù)端是否調(diào)用了阻塞式dbus_connection_read_writedbus-broker與dbus-daemon行為不一致策略實(shí)現(xiàn)差異導(dǎo)致偶發(fā)拒絕system bus使用dbus-broker的發(fā)行版在/usr/share/dbus-1/system.d里對(duì)某些語法支持有差異更換為dbus-daemon測(cè)試同一策略是否復(fù)現(xiàn)Qt程序在非X11環(huán)境收不到session bus未正確設(shè)置DBUS_SESSION_BUS_ADDRESS環(huán)境變量echo $DBUS_SESSION_BUS_ADDRESS窗口環(huán)境由會(huì)話管理器設(shè)置無桌面環(huán)境下手動(dòng)指定地址6.1 調(diào)試三板斧先看名字再看消息最后看進(jìn)程我的調(diào)試順序基本固定。第一板斧確認(rèn)服務(wù)名字是否存在于總線上這一步用一條dbus-send --print-reply就能判斷。如果名字不存在要么是服務(wù)沒起來要么是注冊(cè)失敗。第二板斧開dbus-monitor看消息有沒有到達(dá)目標(biāo)、目標(biāo)有沒有返回錯(cuò)誤。這是判斷調(diào)用是否到達(dá)服務(wù)端的最快方法。第三板斧如果消息到了服務(wù)端但沒反應(yīng)用strace -p pid看服務(wù)進(jìn)程到底卡在什么地方比如是不是在等鎖、等IO、或死循環(huán)。這三板斧能解決九成的D-Bus問題。前兩層定位“鏈路通不通”最后一層定位“服務(wù)端為什么沒處理好”。6.2 用GDBus調(diào)試命令做接口掃描除了dbus-sendgdbus命令也很有用。它有一個(gè)introspect子命令可以列出指定對(duì)象下的所有接口、方法、信號(hào)、屬性# 查看NetworkManager的根對(duì)象提供了什么接口 gdbus introspect --system --dest org.freedesktop.NetworkManager --object-path /org/freedesktop/NetworkManager返回結(jié)果是一段XML描述里面列出了每個(gè)接口的方法簽名和信號(hào)簽名。這個(gè)命令比dbus-send更友好因?yàn)楹灻苯涌梢娔悴挥萌ゲ聟?shù)類型。配合dbus-send做實(shí)際調(diào)用效率非常高。6.3 關(guān)于性能的幾點(diǎn)思考最后聊一下性能。D-Bus因?yàn)橐?jīng)過守護(hù)進(jìn)程轉(zhuǎn)發(fā)單次調(diào)用延遲通常比純unix socket直連高一個(gè)量級(jí)但絕對(duì)數(shù)值仍然很低——在本地socket上一次method_call的往返延遲大致是幾十微秒到幾百微秒級(jí)別。這個(gè)量級(jí)對(duì)桌面交互完全夠用但如果把它用在“每毫秒傳一次傳感器數(shù)據(jù)”的高頻場(chǎng)景就不合適了。批量數(shù)據(jù)傳輸也不要走D-Bus共享內(nèi)存或者臨時(shí)文件才更明智。D-Bus適合的是控制類消息而不是數(shù)據(jù)流。在嵌入式設(shè)備上我見過不少濫用D-Bus的例子有人把音頻PCM數(shù)據(jù)切成小塊用D-Bus signal來傳結(jié)果一卡一卡換成共享內(nèi)存后馬上就順了。在一個(gè)具體項(xiàng)目里我們做了個(gè)雙進(jìn)程方案通過D-Bus傳遞控制指令通過memfd內(nèi)存文件描述符共享大塊數(shù)據(jù)兼顧了解耦與性能。這種組合拳是我現(xiàn)在推薦的實(shí)踐。6.4 寫服務(wù)端時(shí)的血淚建議如果你要自己實(shí)現(xiàn)一個(gè)D-Bus服務(wù)有幾條經(jīng)驗(yàn)是書本上不會(huì)重點(diǎn)講的。第一注冊(cè)名字時(shí)要處理NameOwnerChanged信號(hào)——當(dāng)你的服務(wù)異常退出時(shí)總線會(huì)廣播這個(gè)信號(hào)依賴你的客戶端能據(jù)此做重連或降級(jí)處理不要指望客戶端自己檢測(cè)。第二方法實(shí)現(xiàn)里不要做長時(shí)間阻塞。D-Bus調(diào)用是同步等待語義服務(wù)端阻塞太久會(huì)讓客戶端顯得像卡死實(shí)際上客戶端進(jìn)程也沒死只是等不到回復(fù)。第三服務(wù)端進(jìn)程不要調(diào)用dbus_connection_close后接著退出要等disconnect流程處理完成否則總線上殘留的狀態(tài)可能讓客戶端誤判。實(shí)測(cè)中我維護(hù)的一個(gè)監(jiān)控服務(wù)偶爾會(huì)出現(xiàn)“客戶端報(bào)ServiceUnknown但服務(wù)進(jìn)程還活著”的現(xiàn)象后來定位到原因是服務(wù)注冊(cè)名字后沒有及時(shí)處理總線分配的唯一名與well-known name的關(guān)聯(lián)導(dǎo)致競(jìng)態(tài)。類似這種底層細(xì)節(jié)只能靠對(duì)信號(hào)機(jī)制多下功夫沒有捷徑。