From our system administrator's point of view, dbus is a bit like systemd.
Most of the time we're unaware of it's existence but it's an essential part of most modern Linux distributions.
But what *is* it and what does it do?
The plain truth is that dbus is an inter process communication bus or [IPC](https://en.wikipedia.org/wiki/Inter-process_communication).
Each program of server we launch is an independent *process* that is managed by our operating system.
It will claim the necessary memory it needs to run, to store data and variables, but this chunk of memory is exclusive to the process.
No other processes *should* be able to access this memory and data.
But how can programs talk to each other if they need to?
This is where dbus comes on the scene.
Dbus allows for programs to expose variables and method, functions the program can execute, to the other program connected to dbus.
The program exposing has full control over what it will **do** when methods are called or variables accessed.
Dbus is in charge of connecting and delivering what it's client demand of each other.
While this sounds simple, it does this with grate care and precision.
The dbus [specification](https://dbus.freedesktop.org/doc/dbus-specification.html) states that:
> D-Bus is a system for low-overhead, easy to use interprocess communication (IPC). In more detail:
> * D-Bus is low-overhead because it uses a binary protocol, and does not have to convert to and from a text format such as XML. Because D-Bus is intended for potentially high-resolution same-machine IPC, not primarily for Internet IPC, this is an interesting optimization. D-Bus is also designed to avoid round trips and allow asynchronous operation, much like the X protocol.
> * D-Bus is easy to use because it works in terms of messages rather than byte streams, and automatically handles a lot of the hard IPC issues. Also, the D-Bus library is designed to be wrapped in a way that lets developers use their framework's existing object/type system, rather than learning a new one specifically for IPC.
## Two different busses
On most machines you'll encounter two different, and independent, busses.
* a system bus used by the system to communicate
* a session bus (per logged in user) for programs run by the user
This separation is needed from both practical and security stand point.
Practically speaking I want to control *my* VLC player and not some other one.
From a security point of view unprivileged users should not be allowed to circumvent permissions by hopping on the system bus and triggering all sorts of things they are not allowed to!
Let's have a look at what's running on my home computer.
The most general way to invoke it is with either `--system` or `--session`.
We've already looked at the session bus so let's now look at the system bus.
Let's one op one terminal, run `sudo dbus-monitor --system` and keep it running.
In a second terminal stop one of your running services, such as ssh.
You'll see a bunch of messages appearing in the monitor terminal.
Start the service back up.
Do you understand what is happening here?
Try and visualize both terminals at the same time as in the screenshot below.
Try some tabcomplete and see what is happening.
## Sending messages
We can send things over dbus ourselves with the `dbus-send` program but first we'll use a special program that's very handy to send messages to the notification program of our desktop environment.
It's called `notify-send` and you can install it by installing the `libnotify-bin` package ins Debian.
Once it's installed try it out as follows.
```
➜ ~ git:(master) ✗ notify-send "hello"
➜ ~ git:(master) ✗
```
It immediately return but a notification should have popped up on your screen.
You can use this from within bash scripts to signal the user about updates or errors.
But let's dig a little deeper to see what's happening on the inside.
For this we need to inspect the session bus and post a message again.
Look for your message and observe the method that was called.
