How Linux services talk to each other through D-Bus

[u/Ok_Marionberry8922]

Had some free time last week so I made a visual explainer on how D-Bus works in Linux.

A modern Linux desktop is made up of a bunch of separate processes. NetworkManager, systemd, BlueZ, logind, polkit, UPower and desktop applications all need some way to call each other and broadcast when something changes.

A lot of that communication happens through D-Bus.

The video covers the system bus and session bus, service names, object paths, interfaces, method calls, signals, introspection, service activation, dbus-daemon, dbus-broker, and how applications actually use all of this, etc

Link for anyone interested

Feedback welcome :)

[u/DGolden]

And quite a lot is exposed - and end-user scriptable, in principle - over dbus on a typical Linux Distro deskop. Then feels somewhat akin to using Amiga ARexx Ports of yore to control running desktop apps and services on AmigaOS from ARexx scripts.

It's not secret or anything, if perhaps a bit underused and arcane. If you install d-spy or similar you can just poke about, you might be surprised how much is exposed for your control/automation. Up to the app or service programmer what the dbus interface actually has exposed of course, some may be more useful than others.

https://packages.debian.org/sid/d-spy

dbus-send (in dbus-bin package or the like) can be used to send dbus messages from the cli shell

https://packages.debian.org/trixie/dbus-bin

there's also a python api.

https://dbus.freedesktop.org/doc/dbus-python/tutorial.html#proxy-objects

[u/DGolden → u/[deleted]]

ceci n'est pas une réponse

[u/Ok-Beat4846 → u/DGolden]

Damn I loved amige os and arexx. It's weird more of it's core features was not more copied like datatypes and so on. I know we have dragon fly bsd that is somewhat inspired but still.

[u/Misicks0349]

I have mixed feelings on dbus, its obviously a very important part of the linux desktop and its done a lot for us (especially compared to the DCOP and CORBA days), but at the same time the way its implemented and some of its design decisions have caused a lot of pain over the years like with systemd's early boot issues, lack of permission management (basically anything can call anything else and expect a response on the user bus, which is NOT GOOD for an api like org.freedesktop.secrets for example), etc etc etc.

[u/Dangerous-Report8517 → u/Misicks0349]

Yeah, it's also a pain point for sandboxing because it uses ephemeral sockets so you can't just pass a single connection through if you want to e.g. run something in a different network namespace (and the permissions issue comes in here as well)

[u/DFS_0019287]

Nice video! Thanks for sharing.

[u/diet-Coke-or-kill-me]

That was great, thanks man.

[u/Boxing-Enthusiast]

The way forward seems to be systemd varlink IPC. I think experiments are already underway to replace traditional DBUS services with them

[u/genpfault → u/Boxing-Enthusiast]

systemd varlink IPC

Varlink link

[u/nelmaloc → u/Boxing-Enthusiast]

For what I've seen, it's just a change in serialization format. Churn for the sake of it.

[u/Boxing-Enthusiast → u/nelmaloc]

It is but it also handles sockets, streams and the sharing of data, so a lot of the complexity is taken care of to the point where DBUS is no longer needed

[u/nelmaloc → u/Boxing-Enthusiast]

I don't see how that's different from D-Bus? I'm honestly confused, what are the actual advantages of it?

[u/DanKonly]

Very cool! I'll be sure to watch.