summaryrefslogtreecommitdiffstats
path: root/man/sd_bus_default.xml
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-07 15:35:18 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-07 15:35:18 +0000
commitb750101eb236130cf056c675997decbac904cc49 (patch)
treea5df1a06754bdd014cb975c051c83b01c9a97532 /man/sd_bus_default.xml
parentInitial commit. (diff)
downloadsystemd-b750101eb236130cf056c675997decbac904cc49.tar.xz
systemd-b750101eb236130cf056c675997decbac904cc49.zip
Adding upstream version 252.22.upstream/252.22upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'man/sd_bus_default.xml')
-rw-r--r--man/sd_bus_default.xml349
1 files changed, 349 insertions, 0 deletions
diff --git a/man/sd_bus_default.xml b/man/sd_bus_default.xml
new file mode 100644
index 0000000..cee0748
--- /dev/null
+++ b/man/sd_bus_default.xml
@@ -0,0 +1,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>