Have you ever tried to develop an entire application that relies on d-bus(without knowing too much of d-bus) and when you had to run that application in a headless server, all of the sudden everything stops to work?
Well... That's basically what I did.
Today, we gonna talk about the differences between system bus and session bus, and why it is important for you to develop your application with the correct term in mind.
Session Bus
Session bus is a special term for d-bus that identifies a message bus
(communication) between processes, and is tied to user connection. You can use a session bus if your application has the necessity to run for this single user and is tied to that environment, the session. But keep in mind that it will require that your application runs on a server that has graphical display capabilities
Examples of that:
- KDE
- GNOME
- etc...
System Bus
System bus, on the other hand, is used for system-wide process communication, they do not require a graphical session (like the Session Bus), and can be executed in headless servers without any problems. System bus is indicated for you to use whenever you have to develop an application that needs to communicate with another service in that server/computer, and does not necessarily depend on anything graphical.
Why the difference between the two matters?
The difference between the two is important to know, mainly when developing a new application. If you want to develop something that will run in a server/cloud/ephemeral environment, you need to keep this in mind, as those type of machines won't have a graphical display available for you. You need to know which type of message bus to connect before you can publish your code to production.
In the end, you won't have a lot of headache if you choose to develop your service in with the "wrong" kind of message bus, but, that could mean that you will have to patch, delay, and possibly adapt your workflow to make it work with the correct bus.
How do I choose the correct bus?
Essentially, you should follow a very simple rule. If you are developing a new daemon that needs to notify the user about something (that is running in the backend), your daemon needs graphical access or to communicate with KDE, GNOME etc... That is the perfect use case for a session bus.
If you are developing a service that will talk with an external backend service (let's say an API), do some calculations, won't need to update any UI elements or, and will need to communicate with more system services, then you can go with a system bus.
It's that simple.
A specific note about the system bus option
System bus has a particularity that it needs to be told here. If you are running your service with a regular session bus, you won't need any extra tweaks or tricks, as you are already authenticated and using the user session, the bus will be automatically set that your user will be able to interact with it.
However, for the system bus, since that doesn't require a graphical session, you will need to create a .conf file under a specific folder managed by dbus to allow your service to own the name in the bus, and also, specify which users can send and receive messages from your dbus.
The file looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<!-- Allow the service to own the name -->
<policy context="default">
<allow own="com.example.service"/>
</policy>
<!-- Allow any user to invoke methods -->
<policy context="default">
<allow send_destination="com.example.service"/>
<allow receive_sender="com.example.service"/>
</policy>
</busconfig>
And it should be placed under: /etc/dbus-1/system.d/com.example.service.conf
By doing that, you will be able to let your service acquire the bus name you want and make also allow the specific users to communicate with it.
Top comments (0)