mirror of
https://github.com/systemd/systemd-stable.git
synced 2024-12-24 21:34:08 +03:00
11a1589223
Files which are installed as-is (any .service and other unit files, .conf files, .policy files, etc), are left as is. My assumption is that SPDX identifiers are not yet that well known, so it's better to retain the extended header to avoid any doubt. I also kept any copyright lines. We can probably remove them, but it'd nice to obtain explicit acks from all involved authors before doing that.
306 lines
13 KiB
XML
306 lines
13 KiB
XML
<?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">
|
||
|
||
<!--
|
||
SPDX-License-Identifier: LGPL-2.1+
|
||
|
||
This file is part of systemd.
|
||
|
||
Copyright 2014 Zbigniew Jędrzejewski-Szmek
|
||
-->
|
||
|
||
<refentry id="sd_bus_default">
|
||
|
||
<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>
|
||
<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_user</refname>
|
||
<refname>sd_bus_open_system</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_user</function></funcdef>
|
||
<paramdef>sd_bus **<parameter>bus</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_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>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 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. See
|
||
<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>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_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 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
|
||
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>
|
||
</refsect1>
|
||
|
||
<refsect1>
|
||
<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>-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, any further connection-related errors may be
|
||
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>
|
||
|
||
<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 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>
|