-<?xml version='1.0'?> <!--*- Mode: nxml; nxml-child-indent: 2; indent-tabs-mode: nil -*-->
+<?xml version='1.0'?>
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//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>
<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>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
by returned. See <citerefentry><refentrytitle>sd_bus_send</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para>
</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