SD_BUS_ADD_OBJECT(3)
💖 SD_BUS_ADD_OBJECT(3) 💖
Okay bestie, welcome to the SD_BUS_ADD_OBJECT(3) page — this is the sd_bus_add_object manual, and it's literally the main character energy for declaring your D-Bus object paths, interfaces, methods, properties, and signals. 🦋 No cap, it's giving “make your service's D-Bus surface iconic” and I'm obsessed.
✨ NAME ✨
This whole page is here to declare properties and methods for a D-Bus path — periodt. The full squad named in this manual is: sd_bus_add_object, sd_bus_add_fallback, sd_bus_add_object_vtable, sd_bus_add_fallback_vtable, sd_bus_add_filter, SD_BUS_VTABLE_CAPABILITY, SD_BUS_VTABLE_START, SD_BUS_VTABLE_END, SD_BUS_METHOD_WITH_NAMES_OFFSET, SD_BUS_METHOD_WITH_NAMES, SD_BUS_METHOD_WITH_OFFSET, SD_BUS_METHOD, SD_BUS_SIGNAL_WITH_NAMES, SD_BUS_SIGNAL, SD_BUS_WRITABLE_PROPERTY, SD_BUS_PROPERTY, and SD_BUS_PARAM. 💅
🌸 SYNOPSIS 🌸
First, the include. Then all the function pointer typedefs and function/macro signatures, exactly as they are — do not freestyle these, bestie, copy them character for character: 😭
#include <systemd/sd-bus-vtable.h>
typedef int (*sd_bus_message_handler_t)(sd_bus_message *m,
void *userdata,
sd_bus_error *ret_error);
typedef int (*sd_bus_property_get_t)(sd_bus *bus, const char *path,
const char *interface,
const char *property,
sd_bus_message *reply,
void *userdata,
sd_bus_error *ret_error);
typedef int (*sd_bus_property_set_t)(sd_bus *bus, const char *path,
const char *interface,
const char *property,
sd_bus_message *value,
void *userdata,
sd_bus_error *ret_error);
typedef int (*sd_bus_object_find_t)(const char *path,
const char *interface,
void *userdata, void **ret_found,
sd_bus_error *ret_error);
int sd_bus_add_object(sd_bus *bus, sd_bus_slot **slot, const char *path,
sd_bus_message_handler_t callback,
void *userdata);
int sd_bus_add_fallback(sd_bus *bus, sd_bus_slot **slot,
const char *path,
sd_bus_message_handler_t callback,
void *userdata);
int sd_bus_add_object_vtable(sd_bus *bus, sd_bus_slot **slot,
const char *path, const char *interface,
const sd_bus_vtable *vtable,
void *userdata);
int sd_bus_add_fallback_vtable(sd_bus *bus, sd_bus_slot **slot,
const char *prefix,
const char *interface,
const sd_bus_vtable *vtable,
sd_bus_object_find_t find,
void *userdata);
int sd_bus_add_filter(sd_bus *bus, sd_bus_slot **slot,
sd_bus_message_handler_t callback,
void *userdata);
SD_BUS_VTABLE_CAPABILITY(capability)
SD_BUS_VTABLE_START(flags)
SD_BUS_VTABLE_END
SD_BUS_METHOD_WITH_ARGS_OFFSET(member, args, result, handler, offset,
flags)
SD_BUS_METHOD_WITH_ARGS(member, args, result, handler, flags)
SD_BUS_METHOD_WITH_NAMES_OFFSET(member, signature, in_names, result,
out_names, handler, offset, flags)
SD_BUS_METHOD_WITH_NAMES(member, signature, in_names, result, out_names,
handler, flags)
SD_BUS_METHOD_WITH_OFFSET(member, signature, result, handler, offset,
flags)
SD_BUS_METHOD(member, signature, result, handler, flags)
SD_BUS_SIGNAL_WITH_ARGS(member, args, flags)
SD_BUS_SIGNAL_WITH_NAMES(member, signature, names, flags)
SD_BUS_SIGNAL(member, signature, flags)
SD_BUS_WRITABLE_PROPERTY(member, signature, get, set, offset, flags)
SD_BUS_PROPERTY(member, signature, get, offset, flags)
SD_BUS_PARAM(name)
SD_BUS_ARGS(...)
SD_BUS_RESULT(...)
SD_BUS_NO_ARGS
SD_BUS_NO_RESULT🦋 DESCRIPTION 🦋
So sd_bus_add_object_vtable() is the one you call to declare attributes for the object path path connected to the bus connection bus under the interface interface. The table vtable can contain property declarations via SD_BUS_PROPERTY() or SD_BUS_WRITABLE_PROPERTY(), method declarations via SD_BUS_METHOD(), SD_BUS_METHOD_WITH_NAMES(), SD_BUS_METHOD_WITH_OFFSET(), or SD_BUS_METHOD_WITH_NAMES_OFFSET(), and signal declarations via SD_BUS_SIGNAL_WITH_NAMES() or SD_BUS_SIGNAL() — see below, iykyk. The userdata parameter is a pointer that gets passed to various callback functions. It may be specified as NULL if no value is necessary. An interface can have any number of vtables attached to it. ✨
sd_bus_add_fallback_vtable() is similar to sd_bus_add_object_vtable(), but it's used to register "fallback" attributes. When sd-bus is looking for an attribute declaration, bus object paths registered with sd_bus_add_object_vtable() are checked first. If no match is found, the fallback vtables are checked for each prefix of the bus object path — i.e. with the last slash-separated components successively removed. This lets the vtable be used for an arbitrary number of dynamically created objects. Obsessed. 🎀
The parameter find is a function used to locate the target object based on the bus object path path. It must return 1 and set the ret_found output parameter if the object is found, return 0 if the object was not found, and return a negative errno-style error code or initialize the error structure ret_error on error. The pointer passed in ret_found will be used as the userdata parameter for the callback functions — offset by the offset offsets as specified in the vtable entries. 💀
sd_bus_add_object() attaches a callback directly to the object path path. An object path can have any number of callbacks attached to it. Each callback is prepended to the list of callbacks, which are always called in order. sd_bus_add_fallback() is similar to sd_bus_add_object() but applies to fallback paths instead. 🫶
sd_bus_add_filter() installs a callback that is invoked for each incoming D-Bus message. Filters can be used to handle logic common to all messages received by a service — e.g. authentication or authorization. It's giving bouncer-at-the-club energy, but for messages. 🚪
When a request is received, any associated callbacks are called sequentially until a callback returns a non-zero integer. Return zero from a callback to give other callbacks the chance to process the request. The callbacks are called in this exact order: first, global callbacks installed with sd_bus_add_filter() are called. Second, callbacks attached directly to the request object path are called, followed by any D-Bus method callbacks attached to the request object path, interface, and member. Finally, the property callbacks attached to the request object path, interface, and member are called. If the final callback returns zero, an error reply is sent back to the caller indicating no matching object for the request was found. 👑
Not me about to tell you a slay detail: you can return a positive integer from a method callback without immediately sending a reply. This informs sd-bus that this callback will take responsibility for replying to the request without forcing the callback to produce a reply immediately. That allows a callback to perform any number of asynchronous operations required to construct a reply. However — highkey important — if producing a reply takes too long, the method call will time out at the caller. This is only available to methods and not properties. ⏳
If a callback was invoked to handle a request that expects a reply, and the callback returns a negative value, that value is interpreted as a negative errno-style error code and sent back to the caller as a D-Bus error — as if sd_bus_reply_method_errno(3) was called. Additionally, all callbacks take an sd_bus_error output parameter that can be used to provide more detailed error information. If ret_error is set when the callback finishes, the corresponding D-Bus error is sent back to the caller as if sd_bus_reply_method_error(3) was called. Any error stored in ret_error takes priority over any negative values returned by the same callback when determining which error to send back to the caller. Use sd_bus_error_set(3) or one of its variants to set ret_error and return a negative integer from a callback with a single function call. To send an error reply after a callback has already finished, use sd_bus_reply_method_errno(3) or one of its variants. 😭
For all functions, a match slot is created internally. If the output parameter slot is NULL, a "floating" slot object is created — see sd_bus_slot_set_floating(3). Otherwise, a pointer to the slot object is returned. In that case, the reference to the slot object should be dropped when the vtable is not needed anymore — see sd_bus_slot_unref(3). 🧚
🎀 The sd_bus_vtable array 🎀
The array consists of structures of type sd_bus_vtable, but it should never be filled in manually — instead, use one of the following macros. This is the part where the macros do the iconic work. 💅
SD_BUS_VTABLE_START(flags), SD_BUS_VTABLE_END
Those must always be the first and last element. The flags parameter can be used to set attributes that apply to the whole array; see the "Flags" section below. 🎀
SD_BUS_METHOD_WITH_ARGS_OFFSET(), SD_BUS_METHOD_WITH_ARGS()
Declare a D-Bus method with the name member, arguments args, and result result. args expects a sequence of argument type/name pairs wrapped in the SD_BUS_ARGS() macro. The elements at even indices in this list describe the types of the method's arguments. The method's parameter signature is the concatenation of all the string literals at even indices in args. If a method has no parameters, pass SD_BUS_NO_ARGS to args. The elements at uneven indices describe the names of the method's arguments. result expects a sequence of type/name pairs wrapped in the SD_BUS_RESULT() macro in the same format as SD_BUS_ARGS(). The method's result signature is the concatenation of all the string literals at even indices in result. If a method has no result, pass SD_BUS_NO_RESULT to result. Note that argument types are expected to be quoted string literals and argument names are expected to be unquoted string literals. See below for a complete example. 🔥
The handler function handler must be of type sd_bus_message_handler_t. It will be called to handle the incoming messages that call this method. It receives a pointer that is the userdata parameter passed to the registration function offset by offset bytes. This may be used to pass pointers to different fields in the same data structure to different methods in the same vtable. To send a reply from handler, call sd_bus_reply_method_return(3) with the message the callback was invoked with. The parameter flags is a combination of flags — see below. ⭐
SD_BUS_METHOD_WITH_ARGS() is a shorthand for calling SD_BUS_METHOD_WITH_ARGS_OFFSET() with an offset of zero. Slay. 💅
SD_BUS_METHOD_WITH_NAMES_OFFSET(),SD_BUS_METHOD_WITH_NAMES(),SD_BUS_METHOD_WITH_OFFSET(),SD_BUS_METHOD()— bestie, these declare a D-Bus method with the name member, parameter signature signature, and result signature result. The in_names and out_names params are literally just the argument names of the input and output args in the function signature, and you gotta build them with theSD_BUS_PARAM()macro (peep below 👇). Everything else about these? Identical behaviour toSD_BUS_METHOD_WITH_ARGS_OFFSET(), no cap.
SD_BUS_METHOD_WITH_NAMES(), SD_BUS_METHOD_WITH_OFFSET() and SD_BUS_METHOD() are the variants that set a zero offset (so the userdata parameter gets passed through with no change), leave the names unset (i.e. no parameter names), or both.
Honestly? PreferSD_BUS_METHOD_WITH_ARGS_OFFSET()andSD_BUS_METHOD_WITH_ARGS()over these. They let you put argument types and names right next to each other, which is so much less error-prone than listing all the types first and then all the names. it's giving "bug waiting to happen" otherwise 😭
SD_BUS_SIGNAL_WITH_ARGS()— declares a D-Bus signal named member with arguments args. The args param wants a sequence of argument type/name pairs all wrapped up in theSD_BUS_ARGS()macro 🎀. The elements at even indices in that list are the types of the signal's arguments, and the signal's parameter signature is the concatenation of all the string literals at even indices in args. If a signal has no params at all, just passSD_BUS_NO_ARGSto args. The elements at uneven indices are the names of the signal's arguments. Parameter flags is a combination of flags — full example is down below, don't worry 💅SD_BUS_SIGNAL_WITH_NAMES(),SD_BUS_SIGNAL()— declare a D-Bus signal with the name member, parameter signature signature, and argument names names. That names param should be built with theSD_BUS_PARAM()macro, see below ✨. Parameter flags is a combination of flags, also see below.
SD_BUS_SIGNAL() is equivalent to SD_BUS_SIGNAL_WITH_NAMES() with the names parameter unset (so, no parameter names).
Again, prefer SD_BUS_SIGNAL_WITH_ARGS() over these two, because types-and-names-side-by-side is wayyyyy less error-prone than types-then-names. trust 🫶
SD_BUS_WRITABLE_PROPERTY(),SD_BUS_PROPERTY()— declare a D-Bus property with the name member and value signature signature. Parameters get and set are the getter and setter methods. They get called with a pointer that is the userdata parameter passed to the registration function, offset by offset bytes. This is lowkey iconic because you can pass pointers to different fields in the same data structure to different setters and getters in the same vtable 👑. Parameter flags is a combination of flags, see below.
The setter and getter methods may be omitted (specified as NULL) if the property is one of the basic types, or "as" in the case of read-only properties. When you do that, the userdata and offset parameters must together point to a valid variable of the corresponding type, and a default setter and getter get provided for you which simply copy the argument between this variable and the message. slay, free code 💖
SD_BUS_PROPERTY() is the one used to define a read-only property.
SD_BUS_PARAM()— parameter names should be wrapped in this macro. Example below, iykyk 🌸
🚩 Flags 🚩
The flags parameter is used to specify a combination of D-Bus annotations[1]. Here's the whole menu, no skips 🍓
SD_BUS_VTABLE_DEPRECATED— marks this vtable entry as deprecated using theorg.freedesktop.DBus.Deprecatedannotation in introspection data. If you specify it forSD_BUS_VTABLE_START(), the annotation gets applied to the whole enclosing interface. 💀SD_BUS_VTABLE_HIDDEN— makes this vtable entry hidden. It will not be shown in introspection data. And if you specify it forSD_BUS_VTABLE_START(), literally all entries in the array are hidden. 🙈SD_BUS_VTABLE_METHOD_NO_REPLY— marks this vtable entry as a method that will not return a reply, using theorg.freedesktop.DBus.Method.NoReplyannotation in introspection data.SD_BUS_VTABLE_PROPERTY_CONST,SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE,SD_BUS_VTABLE_PROPERTY_EMITS_INVALIDATION— these three correspond to different values of theorg.freedesktop.DBus.Property.EmitsChangedSignalannotation, which specifies whether theorg.freedesktop.DBus.Properties.PropertiesChangedsignal is emitted whenever the property changes. Get into it:SD_BUS_VTABLE_PROPERTY_CONSTcorresponds toconstand means the property never changes during the lifetime of the object it belongs to, so no signal needs to be emitted. queen of stability 👑SD_BUS_VTABLE_PROPERTY_EMITS_CHANGEcorresponds totrueand means the signal is emitted.SD_BUS_VTABLE_PROPERTY_EMITS_INVALIDATIONcorresponds toinvalidatesand means the signal is emitted, but the value is not included in the signal.
SD_BUS_VTABLE_PROPERTY_EXPLICIT— marks this vtable property entry as requiring an explicit request for the value to be shown (generally because the value is large or slow to calculate, we're not doing that on the default path bestie 😮💨). This entry cannot be combined withSD_BUS_VTABLE_PROPERTY_EMITS_CHANGE, and will not be shown in property listings by default (e.g.busctl introspect). This corresponds to theorg.freedesktop.systemd1.Explicitannotation in introspection data.SD_BUS_VTABLE_SENSITIVE— marks this vtable method entry as processing sensitive data. When it's set, incoming method call messages and their outgoing reply messages are marked as sensitive usingsd_bus_message_sensitive(3), so that they get erased from memory when freed. 🔐 very much "delete the evidence" energy.SD_BUS_VTABLE_ABSOLUTE_OFFSET— marks this vtable method or property entry so that the user data pointer passed to its associated handler functions is determined slightly differently: instead of adding the offset parameter of the entry to the user data pointer specified during vtable registration, the offset is passed directly, converted to a pointer, without taking the user data pointer specified during vtable registration into account. yes it's a whole different vibe for that pointer ✨SD_BUS_VTABLE_CAPABILITY(capability)— access to this vtable entry will be allowed if the calling process has the capability capability, as described insd_bus_query_sender_privilege(3). If used forSD_BUS_VTABLE_START(), it provides a default for all entries in the array. If it's not specified — either for an individual entry or the whole array —CAP_SYS_ADMINis checked by default. Seecapabilities(7)for info about capabilities.
Heads up: vtable entries may be marked as unprivileged, and the whole bus may be marked as trusted — see the discussion of SD_BUS_VTABLE_UNPRIVILEGED below. 👀
SD_BUS_VTABLE_UNPRIVILEGED— marks this vtable entry as unprivileged. Access to privileged entries is limited to users with appropriate capabilities, as described above. In practice, many vtable entries are marked as unprivileged, and either are open to everyone, or the decision whether to allow access is taken later, e.g. by delegating to polkit[2]. main character delegation energy fr fr 💅
The whole bus may be marked as trusted, in which case annotations at the entry level are ignored — see sd_bus_set_trusted(3).
When not specified, the org.freedesktop.systemd1.Privileged annotation with value "true" will be shown in introspection data.
SD_BUS_VTABLE_UNPRIVILEGED may not be applied to read-only properties, but read access (to both read-only and writable properties) is always unrestricted.
Note that this page describes checks implemented in the D-Bus client. The D-Bus server has an additional policy that may permit or deny connections — see"CONFIGURATION FILE"indbus-daemon(1). two different layers, bestie, don't confuse them 🦋
💖 EXAMPLES 💖
🌸 Example 1. Create a simple listener on the bus 🌸
Okay bestie, this is the whole example in one go: a simple listener on the bus, complete with the vtable, the object, the name request, and the process loop. The code is literal and exact, so no edits from me 💅
/* SPDX-License-Identifier: MIT-0 */
#define _GNU_SOURCE 1
#include <errno.h>
#include <stdbool.h>
#include <stddef.h>
#include <stdlib.h>
#include <stdio.h>
#include <systemd/sd-bus.h>
#define _cleanup_(f) __attribute__((cleanup(f)))
typedef struct object {
char *name;
uint32_t number;
} object;
static int method(sd_bus_message *m, void *userdata, sd_bus_error *error) {
int r;
printf("Got called with userdata=%p\n", userdata);
if (sd_bus_message_is_method_call(m,
"org.freedesktop.systemd.VtableExample",
"Method4"))
return 1;
const char *string;
r = sd_bus_message_read(m, "s", &string);
if (r < 0) {
fprintf(stderr, "sd_bus_message_read() failed: %s\n", strerror(-r));
return 0;
}
r = sd_bus_reply_method_return(m, "s", string);
if (r < 0) {
fprintf(stderr, "sd_bus_reply_method_return() failed: %s\n", strerror(-r));
return 0;
}
return 1;
}
static const sd_bus_vtable vtable[] = {
SD_BUS_VTABLE_START(0),
SD_BUS_METHOD(
"Method1", "s", "s", method, 0),
SD_BUS_METHOD_WITH_NAMES_OFFSET(
"Method2",
"so", SD_BUS_PARAM(string) SD_BUS_PARAM(path),
"s", SD_BUS_PARAM(returnstring),
method, offsetof(object, number),
SD_BUS_VTABLE_DEPRECATED),
SD_BUS_METHOD_WITH_ARGS_OFFSET(
"Method3",
SD_BUS_ARGS("s", string, "o", path),
SD_BUS_RESULT("s", returnstring),
method, offsetof(object, number),
SD_BUS_VTABLE_UNPRIVILEGED),
SD_BUS_METHOD_WITH_ARGS(
"Method4",
SD_BUS_NO_ARGS,
SD_BUS_NO_RESULT,
method,
SD_BUS_VTABLE_UNPRIVILEGED),
SD_BUS_SIGNAL(
"Signal1",
"so",
0),
SD_BUS_SIGNAL_WITH_NAMES(
"Signal2",
"so", SD_BUS_PARAM(string) SD_BUS_PARAM(path),
0),
SD_BUS_SIGNAL_WITH_ARGS(
"Signal3",
SD_BUS_ARGS("s", string, "o", path),
0),
SD_BUS_WRITABLE_PROPERTY(
"AutomaticStringProperty", "s", NULL, NULL,
offsetof(object, name),
SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_WRITABLE_PROPERTY(
"AutomaticIntegerProperty", "u", NULL, NULL,
offsetof(object, number),
SD_BUS_VTABLE_PROPERTY_EMITS_INVALIDATION),
SD_BUS_VTABLE_END
};
int main(int argc, char **argv) {
_cleanup_(sd_bus_flush_close_unrefp) sd_bus *bus = NULL;
int r;
sd_bus_default(&bus);
object object = { .number = 666 };
object.name = strdup("name");
if (!object.name) {
fprintf(stderr, "OOM\n");
return EXIT_FAILURE;
}
r = sd_bus_add_object_vtable(bus, NULL,
"/org/freedesktop/systemd/VtableExample",
"org.freedesktop.systemd.VtableExample",
vtable,
&object);
if (r < 0) {
fprintf(stderr, "sd_bus_add_object_vtable() failed: %s\n", strerror(-r));
return EXIT_FAILURE;
}
r = sd_bus_request_name(bus,
"org.freedesktop.systemd.VtableExample",
0);
if (r < 0) {
fprintf(stderr, "sd_bus_request_name() failed: %s\n", strerror(-r));
return EXIT_FAILURE;
}
for (;;) {
r = sd_bus_wait(bus, UINT64_MAX);
if (r < 0) {
fprintf(stderr, "sd_bus_wait() failed: %s\n", strerror(-r));
return EXIT_FAILURE;
}
r = sd_bus_process(bus, NULL);
if (r < 0) {
fprintf(stderr, "sd_bus_process() failed: %s\n", strerror(-r));
return EXIT_FAILURE;
}
}
r = sd_bus_release_name(bus, "org.freedesktop.systemd.VtableExample");
if (r < 0) {
fprintf(stderr, "sd_bus_release_name() failed: %s\n", strerror(-r));
return EXIT_FAILURE;
}
free(object.name);
return 0;
}This creates a simple client on the bus (the user bus, when run as normal user). And if you wanna peek at the XML description of the interface, you may use the D-Bus org.freedesktop.DBus.Introspectable.Introspect call to acquire it. Here's that XML, bestie:
<!DOCTYPE node PUBLIC "-//freedesktop//DTD D-BUS Object Introspection 1.0//EN"
"https://www.freedesktop.org/standards/dbus/1.0/introspect.dtd">
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
<node>
<interface name="org.freedesktop.DBus.Peer">
<method name="Ping"/>
<method name="GetMachineId">
<arg type="s" name="machine_uuid" direction="out"/>
</method>
</interface>
<interface name="org.freedesktop.DBus.Introspectable">
<method name="Introspect">
<arg name="xml_data" type="s" direction="out"/>
</method>
</interface>
<interface name="org.freedesktop.DBus.Properties">
<method name="Get">
<arg name="interface_name" direction="in" type="s"/>
<arg name="property_name" direction="in" type="s"/>
<arg name="value" direction="out" type="v"/>
</method>
<method name="GetAll">
<arg name="interface_name" direction="in" type="s"/>
<arg name="props" direction="out" type="a{sv}"/>
</method>
<method name="Set">
<arg name="interface_name" direction="in" type="s"/>
<arg name="property_name" direction="in" type="s"/>
<arg name="value" direction="in" type="v"/>
</method>
<signal name="PropertiesChanged">
<arg type="s" name="interface_name"/>
<arg type="a{sv}" name="changed_properties"/>
<arg type="as" name="invalidated_properties"/>
</signal>
</interface>
<interface name="org.freedesktop.systemd.VtableExample">
<method name="Method1">
<arg type="s" direction="in"/>
<arg type="s" direction="out"/>
</method>
<method name="Method2">
<arg type="s" name="string" direction="in"/>
<arg type="o" name="path" direction="in"/>
<arg type="s" name="returnstring" direction="out"/>
<annotation name="org.freedesktop.DBus.Deprecated" value="true"/>
</method>
<property name="AutomaticStringProperty" type="s" access="readwrite">
</property>
<property name="AutomaticIntegerProperty" type="u" access="readwrite">
<annotation name="org.freedesktop.DBus.Property.EmitsChangedSignal" value="invalidates"/>
</property>
</interface>
</node>✨ RETURN VALUE ✨
On success, sd_bus_add_object_vtable() and sd_bus_add_fallback_vtable() return a non-negative integer. On failure, they return a negative errno-style error code. That's the whole mood: non-negative = slay, negative = go check the errno 💅
🫶 Errors 🫶
Returned errors may indicate the following problems:
-EINVAL— One of the required parameters isNULLor invalid. A reserved D-Bus interface was passed as the interface parameter.-ENOPKG— The bus cannot be resolved.-ECHILD— The bus was created in a different process, library or module instance.-ENOMEM— Memory allocation failed.-EPROTOTYPE—sd_bus_add_object_vtable()andsd_bus_add_fallback_vtable()have been both called for the same bus object path, which is not allowed.-EEXIST— This vtable has already been registered for this interface and path.
🌈 NOTES 🌈
Functions described here are available as a shared library, which can be compiled against and linked to with the libsystemd pkg-config(1) file. Love that for us 🫶
All functions listed here are thread-agnostic and only a single thread may operate on a given object at any given time. Different threads may access the same object at different times. Multiple independent objects may be used from different threads in parallel.
The code described here uses getenv(3), which is declared to be not multi-thread-safe. This means that the code calling the functions described here must not call setenv(3) from a parallel thread. It is recommended to only do calls to setenv() from an early phase of the program when no other threads have been started. No cap, keep that env setup early ✨
🦋 HISTORY 🦋
sd_bus_property_get_t(), sd_bus_property_set_t(), sd_bus_object_find_t(), sd_bus_add_object(), sd_bus_add_fallback(), sd_bus_add_object_vtable(), sd_bus_add_fallback_vtable(), and sd_bus_add_filter() were added in version 221. Iconic behavior, honestly 👑
👑 SEE ALSO 👑
🎀 NOTES 🎀
The tiny footnote corner, because the page has lore:
- D-Bus annotations —
https://dbus.freedesktop.org/doc/dbus-specification.html#introspection-format - polkit —
https://www.freedesktop.org/software/polkit/docs/latest/
Okay that's the whole page, bestie. This edition is from systemd 261.3 and the page is SD_BUS_ADD_OBJECT(3); the footer didn't print a date, so no fake timestamp from me — just a cute lil sign-off 💅🎀✨
📦 where this page comes from
- ubuntu stonking: libsystemd-dev 261.3-0ubuntu3 · LGPL-2.1-or-later
- 💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms