1SD_BUS_DEFAULT(3) sd_bus_default SD_BUS_DEFAULT(3)
2
6 sd_bus_default, sd_bus_default_user, sd_bus_default_system,
7 sd_bus_open, sd_bus_open_user, sd_bus_open_system,
8 sd_bus_open_system_remote, sd_bus_open_system_machine - Acquire a
9 connection to a system or user bus
10
12 #include <systemd/sd-bus.h>
13 int sd_bus_default(sd_bus **bus);
15 int sd_bus_default_user(sd_bus **bus);
17 int sd_bus_default_system(sd_bus **bus);
19 int sd_bus_open(sd_bus **bus);
21 int sd_bus_open_user(sd_bus **bus);
23 int sd_bus_open_system(sd_bus **bus);
25 int sd_bus_open_system_remote(sd_bus **bus, const char *host);
27 int sd_bus_open_system_machine(sd_bus **bus, const char *machine);
29
31 sd_bus_default() acquires a bus connection object to the user bus when
32 invoked in user context, or to the system bus otherwise. The connection
33 object is associated with the calling thread. Each time the function is
34 invoked from the same thread, the same object is returned, but its
35 reference count is increased by one, as long as at least one reference
36 is kept. When the last reference to the connection is dropped (using
37 the sd_bus_unref(3) call), the connection is terminated. Note that the
38 connection is not automatically terminated when the associated thread
39 ends. It is important to drop the last reference to the bus connection
40 explicitly before the thread ends, as otherwise, the connection will
41 leak. Also, queued but unread or unwritten messages keep the bus
42 referenced, see below.
43 sd_bus_default_user() returns a user bus connection object associated
45 with the calling thread. sd_bus_default_system() is similar, but
46 connects to the system bus. Note that sd_bus_default() is identical to
47 these two calls, depending on the execution context.
48 sd_bus_open() creates a new, independent bus connection to the user bus
50 when invoked in user context, or the system bus otherwise.
51 sd_bus_open_user() is similar, but connects only to the user bus.
52 sd_bus_open_system() does the same, but connects to the system bus. In
53 contrast to sd_bus_default(), sd_bus_default_user(), and
54 sd_bus_default_system(), these calls return new, independent connection
55 objects that are not associated with the invoking thread and are not
56 shared between multiple invocations. It is recommended to share
57 connections per thread to efficiently make use the available resources.
58 Thus, it is recommended to use sd_bus_default(), sd_bus_default_user()
59 and sd_bus_default_system() to connect to the user or system buses.
60 If the $DBUS_SESSION_BUS_ADDRESS environment variable is set (cf.
62 environ(7)), it will be used as the address of the user bus. This
63 variable can contain multiple addresses separated by ";". If this
64 variable is not set, a suitable default for the default user D-Bus
65 instance will be used.
66 If the $DBUS_SYSTEM_BUS_ADDRESS environment variable is set, it will be
68 used as the address of the system bus. This variable uses the same
69 syntax as $DBUS_SESSION_BUS_ADDRESS. If this variable is not set, a
70 suitable default for the default system D-Bus instance will be used.
71 sd_bus_open_system_remote() connects to the system bus on the specified
73 host using ssh(1). host consists of an optional user name followed by
74 the "@" symbol, and the hostname, optionally followed by a ":" and a
75 machine name. If the machine name is given, a connection is created to
76 the system bus in the specified container on the remote machine, and
77 otherwise a connection to the system bus on the specified host is
78 created.
79 Note that entering a container is a privileged operation, and will
81 likely only work for the root user on the remote machine.
82 sd_bus_open_system_machine() connects to the system bus in the
84 specified machine, where machine is the name of a local container. See
85 machinectl(1) for more information about the "machine" concept. Note
86 that connections into local containers are only available to privileged
87 processes at this time.
88 These calls allocate a bus connection object and initiate the
90 connection to a well-known bus of some form. An alternative to using
91 these high-level calls is to create an unconnected bus object with
92 sd_bus_new(3) and to connect it with sd_bus_start(3).
93
95 The functions sd_bus_open(), sd_bus_open_user(), sd_bus_open_system(),
96 sd_bus_open_system_remote(), and sd_bus_open_system_machine() return a
97 new connection object and the caller owns the sole reference. When not
98 needed anymore, this reference should be destroyed with
99 sd_bus_unref(3).
100 The functions sd_bus_default(), sd_bus_default_user() and
102 sd_bus_default_system() do not necessarily create a new object, but
103 increase the connection reference of an existing connection object by
104 one. Use sd_bus_unref(3) to drop the reference.
105 Queued but unwritten/unread messages keep a reference to their bus
107 connection object. For this reason, even if an application dropped all
108 references to a bus connection, it might not get destroyed right away.
109 Until all incoming queued messages are read, and until all outgoing
110 unwritten messages are written, the bus object will stay alive.
111 sd_bus_flush() may be used to write all outgoing queued messages so
112 they drop their references. To flush the unread incoming messages, use
113 sd_bus_close(), which will also close the bus connection. When using
114 the default bus logic, it is a good idea to first invoke sd_bus_flush()
115 followed by sd_bus_close() when a thread or process terminates, and
116 thus its bus connection object should be freed.
117 Normally, slot objects (as created by sd_bus_add_match(3) and similar
119 calls) keep a reference to their bus connection object, too. Thus, as
120 long as a bus slot object remains referenced its bus object will remain
121 allocated too. Optionally, bus slot objects may be placed in "floating"
122 mode. When in floating mode the life cycle of the bus slot object is
123 bound to the bus object, i.e. when the bus object is freed the bus slot
124 object is automatically unreferenced too. The floating state of a slot
125 object may be controlled explicitly with sd_bus_slot_set_floating(3),
126 though usually floating bus slot objects are created by passing NULL as
127 the slot parameter of sd_bus_add_match() and related calls, thus
128 indicating that the caller is not directly interested in referencing
129 and managing the bus slot object.
130 The life cycle of the default bus connection should be the
132 responsibility of the code that creates/owns the thread the default bus
133 connection object is associated with. Library code should neither call
134 sd_bus_flush() nor sd_bus_close() on default bus objects unless it does
135 so in its own private, self-allocated thread. Library code should not
136 use the default bus object in other threads unless it is clear that the
137 program using it will life cycle the bus connection object and flush
138 and close it before exiting from the thread. In libraries where it is
139 not clear that the calling program will life cycle the bus connection
140 object, it is hence recommended to use sd_bus_open_system() instead of
141 sd_bus_default_system() and related calls.
142
144 On success, these calls return 0 or a positive integer. On failure,
145 these calls return a negative errno-style error code.
146
148 Returned errors may indicate the following problems:
149 -EINVAL
151 The specified parameters are invalid.
152 -ENOMEM
154 Memory allocation failed.
155 -ESOCKTNOSUPPORT
157 The protocol version required to connect to the selected bus is not
158 supported.
159 In addition, any further connection-related errors may be by returned.
161 See sd_bus_send(3).
162
164 These APIs are implemented as a shared library, which can be compiled
165 and linked to with the libsystemd pkg-config(1) file.
166
168 systemd(1), sd-bus(3), sd_bus_new(3), sd_bus_ref(3), sd_bus_unref(3),
169 ssh(1), systemd-machined.service(8), machinectl(1)
170systemd 239 SD_BUS_DEFAULT(3)