-<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<?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+ -->
-<!--
- This file is part of systemd.
-
- Copyright 2014 Zbigniew Jędrzejewski-Szmek
-
- systemd is free software; you can redistribute it and/or modify it
- under the terms of the GNU Lesser General Public License as published by
- the Free Software Foundation; either version 2.1 of the License, or
- (at your option) any later version.
-
- systemd is distributed in the hope that it will be useful, but
- WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- Lesser General Public License for more details.
-
- You should have received a copy of the GNU Lesser General Public License
- along with systemd; If not, see <http://www.gnu.org/licenses/>.
--->
-
-<refentry id="sd_bus_default">
+<refentry id="sd_bus_default" xmlns:xi="http://www.w3.org/2001/XInclude">
<refentryinfo>
<title>sd_bus_default</title>
<productname>systemd</productname>
-
- <authorgroup>
- <author>
- <contrib>A monkey with a typewriter</contrib>
- <firstname>Zbigniew</firstname>
- <surname>Jędrzejewski-Szmek</surname>
- <email>zbyszek@in.waw.pl</email>
- </author>
- </authorgroup>
</refentryinfo>
<refmeta>
<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_system</refname>
+ <refname>sd_bus_open_system_with_description</refname>
<refname>sd_bus_open_system_remote</refname>
<refname>sd_bus_open_system_machine</refname>
<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_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>
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
+ 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
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 or otherwise the connection will
- be leaked. Also, queued but unread or unwritten messages keep the
+ 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
<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>,
- <function>sd_bus_default_system()</function> these calls return
+ <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>,
+ <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
+ prefereable 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>),
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 <parameter>host</parameter> 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.
- </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>,
<citerefentry><refentrytitle>sd_bus_unref</refentrytitle><manvolnum>3</manvolnum></citerefentry>
to drop the reference.</para>
- <para>Queued but unwritten/unread messages also 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>The life-cycle of the default bus connection should be the
+ <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
+ 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
+ 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>
<para>On success, these calls return 0 or a positive
integer. On failure, these calls return a negative
errno-style error code.</para>
- </refsect1>
- <refsect1>
- <title>Errors</title>
+ <refsect2>
+ <title>Errors</title>
- <para>Returned errors may indicate the following problems:</para>
+
<para>Returned errors may indicate the following problems:</para>
- <variablelist>
+ <variablelist>
- <varlistentry>
- <term><constant>-EINVAL</constant></term>
+ <varlistentry>
+ <term><constant>-EINVAL</constant></term>
- <listitem><para>The specified parameters are invalid.</para></listitem>
- </varlistentry>
+
<listitem><para>The specified parameters are invalid.</para></listitem>
+ </varlistentry>
- <varlistentry>
- <term><constant>-ENOMEM</constant></term>
+ <varlistentry>
+ <term><constant>-ENOMEM</constant></term>
- <listitem><para>Memory allocation failed.</para></listitem>
- </varlistentry>
+
<listitem><para>Memory allocation failed.</para></listitem>
+ </varlistentry>
- <varlistentry>
- <term><constant>-ESOCKTNOSUPPORT</constant></term>
+ <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>
+ <listitem><para>The protocol version required to connect to the selected bus is not
+ supported.</para></listitem>
+ </varlistentry>
+ </variablelist>
- <para>In addition, any further connection-related errors may be
- by returned. See <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+ <para>In addition, any further connection-related errors may be by returned. See
+ <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
+ </refsect2>
</refsect1>
- <refsect1>
- <title>Notes</title>
-
- <para><function>sd_bus_open_user()</function> and the other
- functions described here are available as a shared library, which
- can be compiled and linked to with the
- <constant>libsystemd</constant> <citerefentry
- project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>
- file.</para>
- </refsect1>
+ <xi:include href="libsystemd-pkgconfig.xml" />
<refsect1>
<title>See Also</title>
projects / thirdparty / systemd.git / blobdiff