man/sd_bus_default.xml - systemd - Git at Google

 <?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 in user context, 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='man-pages'><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='man-pages'><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>
	<?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 <systemd/sd-bus.h></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 in user context, 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='man-pages'><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='man-pages'><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>