SD_BUS_DEFAULT(3)

📦
version 261.3 · 18 versions
, in ubuntu stonking

💅 SD_BUS_DEFAULT(3) — the sd_bus_default manual, bestie edition ✨

okay so listen — this is the sd_bus_default page, and it's literally your whole guide to getting a connection to a system bus or a user bus. yes, that D-Bus thing. no cap, this page is kind of a lot, but we're gonna get through it together 🫶

✨ SYNOPSIS ✨

first things first, you gotta include the header:

#include <systemd/sd-bus.h>

and then, the whole squad of functions (they all basically do variations of "gimme a bus"):

int sd_bus_default(sd_bus **bus);

int sd_bus_default_user(sd_bus **bus);

int sd_bus_default_system(sd_bus **bus);

int sd_bus_open(sd_bus **bus);

int sd_bus_open_with_description(sd_bus **bus, const char *description);

int sd_bus_open_user(sd_bus **bus);

int sd_bus_open_user_with_description(sd_bus **bus,
                                      const char *description);

int sd_bus_open_user_machine(sd_bus **bus, const char *machine);

int sd_bus_open_system(sd_bus **bus);

int sd_bus_open_system_with_description(sd_bus **bus,
                                        const char *description);

int sd_bus_open_system_remote(sd_bus **bus, const char *host);

int sd_bus_open_system_machine(sd_bus **bus, const char *machine);

like, look at all those. iconic. every single one of them is on this page and we're covering all of them 💜

🌸 DESCRIPTION 🌸

the sd_bus_default() family — the "share the vibe" girlies 🎀

sd_bus_default() acquires a bus connection object to the user bus when it's invoked from within a user slice (that's any session under "user-*.slice", for example "user@1000.service"), or to the system bus otherwise. The connection object is associated with the calling thread. every single time the function is invoked from the same thread, you get the same object back, but its reference count is increased by one — as long as at least one reference is being kept. When the last reference to the connection is dropped (using the sd_bus_unref(3) call), the connection is terminated.

⚠️ okay important: the connection is not automatically terminated when the associated thread ends. so you gotta drop that last reference to the bus connection explicitly before the thread ends, or else the connection will leak. not cute. also, queued but unread or unwritten messages keep the bus referenced — more on that below 👇

sd_bus_default_user() returns a user bus connection object associated with the calling thread. sd_bus_default_system() is similar, except it connects to the system bus. and ngl, sd_bus_default() is literally identical to these two calls, it just picks based on the execution context ✨

the sd_bus_open() family — the "I want my own" girlies 🦋

sd_bus_open() creates a new, independent bus connection to the user bus when it's invoked in user context, or to the system bus otherwise. sd_bus_open_user() is similar, but connects only to the user bus. sd_bus_open_system() does the same thing, but connects to the system bus.

so here's the contrast, and it matters: unlike sd_bus_default(), sd_bus_default_user(), and sd_bus_default_system(), these calls return new, independent connection objects that are not associated with the invoking thread and are not shared between multiple invocations. It's recommended to share connections per thread so you efficiently make use of the available resources — so like, the recommendation is to use sd_bus_default(), sd_bus_default_user(), and sd_bus_default_system() to connect to the user or system buses. periodt 💅

the *_with_description() girlies — same but with a name tag 🏷️

sd_bus_open_with_description(), sd_bus_open_user_with_description(), and sd_bus_open_system_with_description() are similar to sd_bus_open(), sd_bus_open_user(), and sd_bus_open_system(), but they let you set a description string — see sd_bus_set_description(3).

description may be NULL, in which case this function is equivalent to sd_bus_open(). This description string gets used in log messages about the bus object, and giving the bus a "name" makes those messages way easier to understand. Some messages are emitted during bus initialization, so using this function is preferable to setting the description later with sd_bus_open_with_description(). The argument is copied internally and will not be referenced after the function returns — so no sneaky dangling stuff, we love that for us 🌈

the environment variables — the plot twist 🌀

  • If the $DBUS_SESSION_BUS_ADDRESS environment variable is set (cf. environ(7)), it will be used as the address of the user bus. This variable can contain multiple addresses separated by ";". If it's not set, a suitable default for the default user D-Bus instance will be used.
  • If the $DBUS_SYSTEM_BUS_ADDRESS environment variable is set, it will be used as the address of the system bus. This variable uses the same syntax as $DBUS_SESSION_BUS_ADDRESS. If it's not set, a suitable default for the default system D-Bus instance will be used.

sd_bus_open_system_remote() — the ssh(1) queen 👑

sd_bus_open_system_remote() connects to the system bus on the specified host, using ssh(1).

so host is made of: an optional user name followed by the "@" symbol, and then the hostname, optionally followed by a ":" and a port, optionally followed by a "/" and a machine name. If the machine name is given, a connection is created to the system bus in the specified container on the remote machine. If it's not given, you get a connection to the system bus on the specified host. iykyk 🐚

🚨 heads up: entering a container is a privileged operation, and it'll likely only work for the root user on the remote machine. so like... don't expect magic as a rando, bestie 😭

sd_bus_open_system_machine() — local containers, let's go 🧚

sd_bus_open_system_machine() connects to the system bus in the specified machine, where machine is the name of a local container, possibly prefixed by a user name and a separating "@".

  • If the container name is specified as the special string ".host", the connection is made to the local system. This is useful to connect to the local system bus as a specific user — e.g. "foobar@.host" to connect to the local system bus as local user "foobar".
  • If the "@" syntax is used, either the left-hand side or the right-hand side may be omitted (but not both), in which case the local user name or ".host" is implied.
  • If the "@" syntax is not used, the connection is always made as root user.

See sd_bus_set_address(3) for a description of the address syntax, and machinectl(1) for more information about the "machine" concept.

💀 and note: connections into local containers are only available to privileged processes at this time. soz.

sd_bus_open_user_machine() — the user-bus sibling 🌸

sd_bus_open_user_machine() is similar to sd_bus_open_system_machine(), but it connects to the user bus of the root user, or — if the "@" syntax is used — of the specified user.

the big picture ⭐

These calls allocate a bus connection object and initiate the connection to a well-known bus of some form. An alternative to using these high-level calls is to create an unconnected bus object with sd_bus_new(3) and to connect it with sd_bus_start(3) — that's the DIY route, if that's your vibe 🛠️

👑 REFERENCE OWNERSHIP 👑

okay this section is lowkey the most important one because someone has to clean up, and bestie, that someone is you 💅

  • The functions sd_bus_open(), sd_bus_open_user(), sd_bus_open_user_machine(), sd_bus_open_system(), sd_bus_open_system_remote(), and sd_bus_open_system_machine() return a new connection object and the caller owns the sole reference. When you don't need it anymore, that reference should be destroyed with sd_bus_unref(3).
  • The functions sd_bus_default(), sd_bus_default_user(), and sd_bus_default_system() don't necessarily create a new object — they increase the connection reference of an existing connection object by one. Use sd_bus_unref(3) to drop the reference.

the queued messages situation 😭

Queued but unwritten/unread messages keep a reference to their bus connection object. Because of this, even if an application dropped all references to a bus connection, it might not get destroyed right away. Until all incoming queued messages are read, and until all outgoing unwritten messages are written, the bus object will stay alive.

  • sd_bus_flush() may be used to write all outgoing queued messages so they drop their references.
  • To flush the unread incoming messages, use sd_bus_close(), which will also close the bus connection.

When you're using the default bus logic, it's a good idea to first invoke sd_bus_flush() followed by sd_bus_close() when a thread or process terminates — and thus its bus connection object should be freed. like, do that. seriously 🫶

slot objects & floating mode 🎈

Normally, slot objects (as created by sd_bus_add_match(3) and similar calls) keep a reference to their bus connection object too. So as long as a bus slot object remains referenced, its bus object will remain allocated too.

Optionally, bus slot objects may be placed in "floating" mode. When in floating mode, the life cycle of the bus slot object is bound to the bus object — i.e. when the bus object is freed, the bus slot object is automatically unreferenced too. The floating state of a slot object may be controlled explicitly with sd_bus_slot_set_floating(3), though usually floating bus slot objects are created by passing NULL as the slot parameter of sd_bus_add_match() and related calls — which is basically saying "I'm not directly interested in referencing and managing this bus slot object," and honestly? valid. 🙈

library code etiquette 🧼

The life cycle of the default bus connection should be the responsibility of the code that creates/owns the thread the default bus connection object is associated with.

🚫 Library code should neither call sd_bus_flush() nor sd_bus_close() on default bus objects — unless it does so in its own private, self-allocated thread. 🚫 Library code should not use the default bus object in other threads unless it's clear that the program using it will life cycle the bus connection object and flush and close it before exiting from the thread.

In libraries where it's not clear that the calling program will life cycle the bus connection object, it's hence recommended to use sd_bus_open_system() instead of sd_bus_default_system() and related calls. no cap, this is the safe girlie move 💖

🌟 RETURN VALUE 🌟

On success, these calls return 0 or a positive integer. On failure, they return a negative errno-style error code. slay ✨

🍓 Errors 🍓

Returned errors may indicate the following problems:

  • -EINVAL — the specified parameters are invalid.
  • -ENOMEDIUM — the requested bus type is not available because of invalid environment (for example the user session bus is not available because $XDG_RUNTIME_DIR is not set).
  • -ENOMEM — memory allocation failed. 😭
  • -ESOCKTNOSUPPORT — the protocol version required to connect to the selected bus is not supported.

In addition, other connection-related errors may be returned. See sd_bus_send(3).

💜 NOTES 💜

  • Functions described here are available as a shared library, which can be compiled against and linked to with the libsystemd pkg-config(1) file.
  • All functions listed here are thread-agnostic and only a single thread may operate on a given object at any given time. Different threads may access the same object at different times. Multiple independent objects may be used from different threads in parallel. so like, one at a time per object, but parallel across different objects — got it? 🦋
  • The code described here uses getenv(3), which is declared to be not multi-thread-safe. This means the code calling the functions described here must not call setenv(3) from a parallel thread. It's recommended to only do calls to setenv() from an early phase of the program, when no other threads have been started — like, get it out of the way first, bestie 🎀

(part 1 done — part 2 is coming, don't go anywhere 👀)

✨ HISTORY ✨

okay so storytime, bestie 📖 — here's the timeline of when all these babies showed up:

  • sd_bus_default(), sd_bus_default_user(), sd_bus_default_system(), sd_bus_open(), sd_bus_open_user(), sd_bus_open_system(), sd_bus_open_system_remote(), and sd_bus_open_system_machine() were added in version 221. iconic behavior, honestly 👑
  • sd_bus_open_with_description(), sd_bus_open_user_with_description(), and sd_bus_open_system_with_description() were added in version 239 — the "with_description" era, we love a glow-up ✨
  • sd_bus_open_user_machine() was added in version 248 🌸

so yeah, this whole squad has been cooking for a minute 💅

💜 SEE ALSO 💜

like, go read these too, fr fr — they're the rest of the lore:

and that's the whole page, bestie 🫶 you made it to the end, I'm so proud 😭💖 this was served up fresh from systemd 261.3, and the page itself is SD_BUS_DEFAULT(3) — go forth and open those buses, you absolute main character 👑🎀🦋

📦 where this page comes from