HTML rendering created 2025-09-06 byMichael Kerrisk, author ofThe Linux Programming Interface. For details of in-depthLinux/UNIX system programming training courses that I teach, lookhere. Hosting byjambit GmbH. |  |
NAME |SYNOPSIS |DESCRIPTION |REFERENCE OWNERSHIP |RETURN VALUE |NOTES |HISTORY |SEE ALSO |COLOPHON | |
SD_BUS_DEFAULT(3) sd_bus_defaultSD_BUS_DEFAULT(3)sd_bus_default, sd_bus_default_user, sd_bus_default_system, sd_bus_open, sd_bus_open_with_description, sd_bus_open_user, sd_bus_open_user_with_description, sd_bus_open_user_machine, sd_bus_open_system, sd_bus_open_system_with_description, sd_bus_open_system_remote, sd_bus_open_system_machine - Acquire a connection to a system or user bus
#include <systemd/sd-bus.h>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);
sd_bus_default()acquires a bus connection object to the user bus when invoked from within a user slice (any session under "user-*.slice", e.g.: "user@1000.service"), or to the system bus otherwise. The connection object is associated with the calling thread. Each time the function is invoked from the same thread, the same object is returned, but its reference count is increased by one, as long as at least one reference is kept. When the last reference to the connection is dropped (using thesd_bus_unref(3) call), the connection is terminated. Note that the connection is not automatically terminated when the associated thread ends. It is important to drop the last reference to the bus connection explicitly before the thread ends, as otherwise, the connection will leak. Also, queued but unread or unwritten messages keep the bus referenced, see below.sd_bus_default_user()returns a user bus connection object associated with the calling thread.sd_bus_default_system()is similar, but connects to the system bus. Note thatsd_bus_default()is identical to these two calls, depending on the execution context.sd_bus_open()creates a new, independent bus connection to the user bus when invoked in user context, or the system bus otherwise.sd_bus_open_user()is similar, but connects only to the user bus.sd_bus_open_system()does the same, but connects to the system bus. In contrast tosd_bus_default(),sd_bus_default_user(), andsd_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 is recommended to share connections per thread to efficiently make use the available resources. Thus, it is recommended to usesd_bus_default(),sd_bus_default_user()andsd_bus_default_system()to connect to the user or system buses.sd_bus_open_with_description(),sd_bus_open_user_with_description(), andsd_bus_open_system_with_description()are similar tosd_bus_open(),sd_bus_open_user(), andsd_bus_open_system(), but allow a description string to be set, seesd_bus_set_description(3).description may beNULL, in which case this function is equivalent tosd_bus_open(). This description string is used in log messages about the bus object, and including a "name" for the bus makes them easier to understand. Some messages are emitted during bus initialization, hence using this function is preferable to setting the description later withsd_bus_open_with_description(). The argument is copied internally and will not be referenced after the function returns. 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 this variable is 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 this variable is not set, a suitable default for the default system D-Bus instance will be used.sd_bus_open_system_remote()connects to the system bus on the specified host usingssh(1).host consists of an optional user name followed by the "@" symbol, and 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, and otherwise a connection to the system bus on the specified host is created. Note that entering a container is a privileged operation, and will likely only work for the root user on the remote machine.sd_bus_open_system_machine()connects to the system bus in the specifiedmachine, wheremachine 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 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. Seesd_bus_set_address(3) for a description of the address syntax, andmachinectl(1) for more information about the "machine" concept. Note that connections into local containers are only available to privileged processes at this time.sd_bus_open_user_machine()is similar tosd_bus_open_system_machine(), but connects to the user bus of the root user, or if the "@" syntax is used, of the specified user. 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 withsd_bus_new(3) and to connect it withsd_bus_start(3).
The functionssd_bus_open(),sd_bus_open_user(),sd_bus_open_user_machine(),sd_bus_open_system(),sd_bus_open_system_remote(), andsd_bus_open_system_machine() return a new connection object and the caller owns the sole reference. When not needed anymore, this reference should be destroyed withsd_bus_unref(3). The functionssd_bus_default(),sd_bus_default_user()andsd_bus_default_system()do not necessarily create a new object, but increase the connection reference of an existing connection object by one. Usesd_bus_unref(3) to drop the reference. Queued but unwritten/unread messages keep a reference to their bus connection object. For this reason, 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, usesd_bus_close(), which will also close the bus connection. When using the default bus logic, it is a good idea to first invokesd_bus_flush()followed bysd_bus_close() when a thread or process terminates, and thus its bus connection object should be freed. Normally, slot objects (as created bysd_bus_add_match(3) and similar calls) keep a reference to their bus connection object, too. Thus, 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 withsd_bus_slot_set_floating(3), though usually floating bus slot objects are created by passingNULLas theslot parameter ofsd_bus_add_match()and related calls, thus indicating that the caller is not directly interested in referencing and managing the bus slot object. 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 callsd_bus_flush()norsd_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 is 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 is not clear that the calling program will life cycle the bus connection object, it is hence recommended to usesd_bus_open_system()instead ofsd_bus_default_system()and related calls.
On success, these calls return 0 or a positive integer. On failure, these calls return a negative errno-style error code.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. Seesd_bus_send(3).
Functions described here are available as a shared library, which can be compiled against and linked to with thelibsystemd pkg-config(1) file. The code described here usesgetenv(3), which is declared to be not multi-thread-safe. This means that the code calling the functions described here must not callsetenv(3) from a parallel thread. It is recommended to only do calls tosetenv()from an early phase of the program when no other threads have been started.
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(), andsd_bus_open_system_machine()were added in version 221.sd_bus_open_with_description(),sd_bus_open_user_with_description(), andsd_bus_open_system_with_description()were added in version 239.sd_bus_open_user_machine()was added in version 248.
systemd(1),sd-bus(3),sd_bus_new(3),sd_bus_ref(3),sd_bus_unref(3),sd_bus_close(3),ssh(1),systemd-machined.service(8),machinectl(1)
This page is part of thesystemd (systemd system and service manager) project. Information about the project can be found at ⟨http://www.freedesktop.org/wiki/Software/systemd⟩. If you have a bug report for this manual page, see ⟨http://www.freedesktop.org/wiki/Software/systemd/#bugreports⟩. This page was obtained from the project's upstream Git repository ⟨https://github.com/systemd/systemd.git⟩ on 2025-08-11. (At that time, the date of the most recent commit that was found in the repository was 2025-08-11.) If you discover any rendering problems in this HTML version of the page, or you believe there is a better or more up-to-date source for the page, or you have corrections or improvements to the information in this COLOPHON (which isnot part of the original manual page), send a mail to man-pages@man7.orgsystemd 258~rc2SD_BUS_DEFAULT(3)Pages that refer to this page:sd-bus(3), sd_bus_close(3), sd_bus_negotiate_fds(3), sd_bus_new(3), sd_bus_set_address(3), sd_bus_set_description(3), sd_bus_set_server(3), sd_bus_start(3), systemd.directives(7), systemd.index(7), systemd-machined.service(8)
HTML rendering created 2025-09-06 byMichael Kerrisk, author ofThe Linux Programming Interface. For details of in-depthLinux/UNIX system programming training courses that I teach, lookhere. Hosting byjambit GmbH. | |