summaryrefslogtreecommitdiffstats
path: root/man/sd_bus_default.xml
blob: cee0748e184c342f2cc6e36a8c4aaff384651357 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
<?xml version='1.0'?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
  "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->

<refentry id="sd_bus_default" xmlns:xi="http://www.w3.org/2001/XInclude">

  <refentryinfo>
    <title>sd_bus_default</title>
    <productname>systemd</productname>
  </refentryinfo>

  <refmeta>
    <refentrytitle>sd_bus_default</refentrytitle>
    <manvolnum>3</manvolnum>
  </refmeta>

  <refnamediv>
    <refname>sd_bus_default</refname>
    <refname>sd_bus_default_user</refname>
    <refname>sd_bus_default_system</refname>

    <refname>sd_bus_open</refname>
    <refname>sd_bus_open_with_description</refname>
    <refname>sd_bus_open_user</refname>
    <refname>sd_bus_open_user_with_description</refname>
    <refname>sd_bus_open_user_machine</refname>
    <refname>sd_bus_open_system</refname>
    <refname>sd_bus_open_system_with_description</refname>
    <refname>sd_bus_open_system_remote</refname>
    <refname>sd_bus_open_system_machine</refname>

    <refpurpose>Acquire a connection to a system or user bus</refpurpose>
  </refnamediv>

  <refsynopsisdiv>
    <funcsynopsis>
      <funcsynopsisinfo>#include &lt;systemd/sd-bus.h&gt;</funcsynopsisinfo>

      <funcprototype>
        <funcdef>int <function>sd_bus_default</function></funcdef>
        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
      </funcprototype>

      <funcprototype>
        <funcdef>int <function>sd_bus_default_user</function></funcdef>
        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
      </funcprototype>

      <funcprototype>
        <funcdef>int <function>sd_bus_default_system</function></funcdef>
        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
      </funcprototype>

      <funcprototype>
        <funcdef>int <function>sd_bus_open</function></funcdef>
        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
      </funcprototype>

      <funcprototype>
        <funcdef>int <function>sd_bus_open_with_description</function></funcdef>
        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
        <paramdef>const char *<parameter>description</parameter></paramdef>
      </funcprototype>

      <funcprototype>
        <funcdef>int <function>sd_bus_open_user</function></funcdef>
        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
      </funcprototype>

      <funcprototype>
        <funcdef>int <function>sd_bus_open_user_with_description</function></funcdef>
        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
        <paramdef>const char *<parameter>description</parameter></paramdef>
      </funcprototype>

      <funcprototype>
        <funcdef>int <function>sd_bus_open_user_machine</function></funcdef>
        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
        <paramdef>const char *<parameter>machine</parameter></paramdef>
      </funcprototype>

      <funcprototype>
        <funcdef>int <function>sd_bus_open_system</function></funcdef>
        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
      </funcprototype>

      <funcprototype>
        <funcdef>int <function>sd_bus_open_system_with_description</function></funcdef>
        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
        <paramdef>const char *<parameter>description</parameter></paramdef>
      </funcprototype>

      <funcprototype>
        <funcdef>int <function>sd_bus_open_system_remote</function></funcdef>
        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
        <paramdef>const char *<parameter>host</parameter></paramdef>
      </funcprototype>

      <funcprototype>
        <funcdef>int <function>sd_bus_open_system_machine</function></funcdef>
        <paramdef>sd_bus **<parameter>bus</parameter></paramdef>
        <paramdef>const char *<parameter>machine</parameter></paramdef>
      </funcprototype>

    </funcsynopsis>
  </refsynopsisdiv>

  <refsect1>
    <title>Description</title>

    <para><function>sd_bus_default()</function> acquires a bus
    connection object to the user bus when invoked from within a user
    slice (any session under <literal>user-*.slice</literal>, e.g.:
    <literal>user@1000.service</literal>), 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 the
    <citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>
    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.</para>

    <para><function>sd_bus_default_user()</function> returns a user
    bus connection object associated with the calling thread.
    <function>sd_bus_default_system()</function> is similar, but
    connects to the system bus. Note that
    <function>sd_bus_default()</function> is identical to these two
    calls, depending on the execution context.</para>

    <para><function>sd_bus_open()</function> creates a new,
    independent bus connection to the user bus when invoked in user
    context, or the system bus
    otherwise. <function>sd_bus_open_user()</function> is similar, but
    connects only to the user bus.
    <function>sd_bus_open_system()</function> does the same, but
    connects to the system bus. In contrast to
    <function>sd_bus_default()</function>,
    <function>sd_bus_default_user()</function>, and
    <function>sd_bus_default_system()</function>, 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 use <function>sd_bus_default()</function>,
    <function>sd_bus_default_user()</function> and
    <function>sd_bus_default_system()</function> to connect to the
    user or system buses.</para>

    <para><function>sd_bus_open_with_description()</function>,
    <function>sd_bus_open_user_with_description()</function>, and
    <function>sd_bus_open_system_with_description()</function> are similar to
    <function>sd_bus_open()</function>, <function>sd_bus_open_user()</function>, and
    <function>sd_bus_open_system()</function>, but allow a description string to be set, see
    <citerefentry><refentrytitle>sd_bus_set_description</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
    <parameter>description</parameter> may be <constant>NULL</constant>, in which case this function
    is equivalent to <function>sd_bus_open()</function>. 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 with
    <function>sd_bus_open_with_description()</function>. The argument is copied internally and will
    not be referenced after the function returns.</para>

    <para>If the <varname>$DBUS_SESSION_BUS_ADDRESS</varname> environment
    variable is set
    (cf. <citerefentry project='man-pages'><refentrytitle>environ</refentrytitle><manvolnum>7</manvolnum></citerefentry>),
    it will be used as the address of the user bus. This variable can
    contain multiple addresses separated by <literal>;</literal>. If
    this variable is not set, a suitable default for the default user
    D-Bus instance will be used.</para>

    <para>If the <varname>$DBUS_SYSTEM_BUS_ADDRESS</varname>
    environment variable is set, it will be used as the address of the
    system bus. This variable uses the same syntax as
    <varname>$DBUS_SESSION_BUS_ADDRESS</varname>. If this variable is
    not set, a suitable default for the default system D-Bus instance
    will be used.</para>

    <para><function>sd_bus_open_system_remote()</function> connects to the system bus on
    the specified host using
    <citerefentry project='die-net'><refentrytitle>ssh</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
    <parameter>host</parameter> consists of an optional user name followed by the
    <literal>@</literal> symbol, and the hostname, optionally followed by a
    <literal>:</literal> and a port, optionally followed by a
    <literal>/</literal> 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.</para>

    <para>Note that entering a container is a privileged operation, and will likely only
    work for the root user on the remote machine.</para>

    <para><function>sd_bus_open_system_machine()</function> connects to the system bus in the specified
    <parameter>machine</parameter>, where <parameter>machine</parameter> is the name of a local container,
    possibly prefixed by a user name and a separating <literal>@</literal>. If the container name is
    specified as the special string <literal>.host</literal> the connection is made to the local system. This
    is useful to connect to the local system bus as specific user, e.g. <literal>foobar@.host</literal> to
    connect to the local system bus as local user <literal>foobar</literal>. If the <literal>@</literal>
    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 <literal>.host</literal> is implied. If the <literal>@</literal> syntax is
    not used the connection is always made as root user. See
    <citerefentry><refentrytitle>sd_bus_set_address</refentrytitle><manvolnum>3</manvolnum></citerefentry>
    for a description of the address syntax, and
    <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry> for more
    information about the "machine" concept. Note that connections into local containers are only available
    to privileged processes at this time.</para>

    <para><function>sd_bus_open_user_machine()</function> is similar to
    <function>sd_bus_open_system_machine()</function>, but connects to the user bus of the root user, or if
    the <literal>@</literal> syntax is used, of the specified user.</para>

    <para>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
    <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>
    and to connect it with
    <citerefentry><refentrytitle>sd_bus_start</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
    </para>

  </refsect1>

  <refsect1>
    <title>Reference ownership</title>
    <para>The functions <function>sd_bus_open()</function>,
    <function>sd_bus_open_user()</function>,
    <function>sd_bus_open_user_machine()</function>,
    <function>sd_bus_open_system()</function>,
    <function>sd_bus_open_system_remote()</function>, and
    <function>sd_bus_open_system_machine()</function> return a new
    connection object and the caller owns the sole reference. When not
    needed anymore, this reference should be destroyed with
    <citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
    </para>

    <para>The functions <function>sd_bus_default()</function>,
    <function>sd_bus_default_user()</function> and
    <function>sd_bus_default_system()</function> do not necessarily
    create a new object, but increase the connection reference of an
    existing connection object by one. Use
    <citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>
    to drop the reference.</para>

    <para>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. <function>sd_bus_flush()</function> may be used to write all outgoing queued messages so they drop their
    references. To flush the unread incoming messages, use <function>sd_bus_close()</function>, which will also close
    the bus connection. When using the default bus logic, it is a good idea to first invoke
    <function>sd_bus_flush()</function> followed by <function>sd_bus_close()</function> when a thread or process
    terminates, and thus its bus connection object should be freed.</para>

    <para>Normally, slot objects (as created by
    <citerefentry><refentrytitle>sd_bus_add_match</refentrytitle><manvolnum>3</manvolnum></citerefentry> 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 with
    <citerefentry><refentrytitle>sd_bus_slot_set_floating</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
    though usually floating bus slot objects are created by passing <constant>NULL</constant> as the
    <parameter>slot</parameter> parameter of <function>sd_bus_add_match()</function> and related calls, thus indicating
    that the caller is not directly interested in referencing and managing the bus slot object.</para>

    <para>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 <function>sd_bus_flush()</function> nor
    <function>sd_bus_close()</function> 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 use <function>sd_bus_open_system()</function>
    instead of <function>sd_bus_default_system()</function> and
    related calls.</para>
  </refsect1>

  <refsect1>
    <title>Return Value</title>

    <para>On success, these calls return 0 or a positive
    integer. On failure, these calls return a negative
    errno-style error code.</para>

    <refsect2>
      <title>Errors</title>

      <para>Returned errors may indicate the following problems:</para>

      <variablelist>
        <varlistentry>
          <term><constant>-EINVAL</constant></term>

          <listitem><para>The specified parameters are invalid.</para></listitem>
        </varlistentry>

        <varlistentry>
          <term><constant>-ENOMEDIUM</constant></term>

          <listitem><para>The requested bus type is not available because of invalid environment (for example
          the user session bus is not available because <varname>$XDG_RUNTIME_DIR</varname> is not set).
          </para></listitem>
        </varlistentry>

        <varlistentry>
          <term><constant>-ENOMEM</constant></term>

          <listitem><para>Memory allocation failed.</para></listitem>
        </varlistentry>

        <varlistentry>
          <term><constant>-ESOCKTNOSUPPORT</constant></term>

          <listitem><para>The protocol version required to connect to the selected bus is not
          supported.</para></listitem>
        </varlistentry>
      </variablelist>

      <para>In addition, other connection-related errors may be returned. See
      <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
    </refsect2>
  </refsect1>

  <xi:include href="libsystemd-pkgconfig.xml" />

  <refsect1>
    <title>See Also</title>

    <para>
      <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
      <citerefentry><refentrytitle>sd-bus</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
      <citerefentry><refentrytitle>sd_bus_new</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
      <citerefentry><refentrytitle>sd_bus_ref</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
      <citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
      <citerefentry><refentrytitle>sd_bus_close</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
      <citerefentry project='die-net'><refentrytitle>ssh</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
      <citerefentry><refentrytitle>systemd-machined.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
      <citerefentry><refentrytitle>machinectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
    </para>
  </refsect1>

</refentry>