Re: [systemd-devel] XML for Systemd DBus?
hey, On Wed, Aug 9, 2023 at 5:58 PM Elsie Hupp wrote: > > Note: I am on elementaryOS 6.0. > > I am trying to generate a vala interface from the Systemd DBus interface, > following the example here to get the XML to feed into > `vala-dbus-binding-tool`: > > https://wiki.gnome.org/Projects/Vala/DBusClientSamples > > But I am getting the following error: > > ```bash > $ dbus-send --print-reply --type=method_call --dest=org.freedesktop.systemd1 > objectpath org.freedesktop.DBus.Introspectable.Introspect > dbus[208973]: arguments to dbus_message_new_method_call() were incorrect, > assertion "_dbus_check_is_valid_path (path)" failed in file > ../../../dbus/dbus-message.c line 1366. > This is normally a bug in some application using the D-Bus library. > the _objectpath_ needs to be an actual path, like '/' (without quotes): $ dbus-send --print-reply --type=method_call --dest=org.freedesktop.systemd1 / org.freedesktop.DBus.Introspectable.Introspect method return time=1691600348.597554 sender=:1.1 -> destination=:1.1897 serial=8426 reply_serial=2 string "https://www.freedesktop.org/standards/dbus/1.0/introspect.dtd;> " you can check the paths with tools like d-feet what is actually there, and also the answers to these queries. For systemd1 the list seems to be rather long, not sure what you want to achieve there... Giacinto > > I did several web searches of the error messages, and none of them were > particularly helpful. > > How do I get the XML for the Systemd DBus interface? Is there a way I can > work around this error, or is there a copy available somewhere online?
Re: [systemd-devel] sd-bus: get size of array container in D-Bus message
On Wed, Aug 2, 2023 at 6:44 PM Stephen Hemminger wrote: > > On Wed, 02 Aug 2023 06:39:47 + > Stanislav Angelovič wrote: > > > Hi folks, > > > > I have a quick question: is there a way to get container size when > > deserializing an array from a D-Bus message (be it an array of trivial or > > non-trivial D-Bus types)? Say I enter a container with > > sd_bus_message_enter_container, and then, before reading individual > > elements, I'd like to get the number of elements in that array in that > > message (so I can reserve storage on my side, etc.). > > > > If not, could such an API function be added? > > > > Thanks in advance. > > > > Stanislav. > > The dbus messsage just an encoding of a byte stream. There is nothing in the > byte stream > that indicates the length. yes, but the whole message is available locally, it could be parsed on request, discarding the data, and keeping only the number of elements in an array.
Re: [systemd-devel] timing issue in mounting systemd filesystems
Hi Lennart, thank you for your help. I found the issue, it is a mismatch between the compiler or libc used for the kernel and the systemd/mount executables. Difference not declared, I managed by accident to find the right cross-compiler. On Wed, Jul 5, 2023 at 10:57 AM Lennart Poettering wrote: > > On Mi, 05.07.23 07:59, Giacinto Cifelli (gciof...@gmail.com) wrote: > > > I have then increased the log level to debug in the kernel cmdline to > > have more info: > > systemd.log_level=debug systemd.log_target=console > > > > and with these settings it boots normally (although much slower). > > output to console is generally much slower. maybe use kmsg instead, or > don't do debug level stuff for now, boot into single user mode only. > > It's usually a good idea to start with saying which systemd version it > is btw, and which distro. it is an out-of-tree debian 11, for VisionFive2, a 4-core riscv (with isa rv64imafdc). It uses: systemd 252 (252.4-1) +PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified > > Also: > > https://freedesktop.org/wiki/Software/systemd/Debugging/#diagnosingbootproblems > > Lennart > > -- > Lennart Poettering, Berlin thanks again - Giacinto, Spandau
[systemd-devel] timing issue in mounting systemd filesystems
Dear community, I have an issue booting on a RV machine. The mount targets fail, and (I suppose) as a consequence everything else fails and the system is not running: [FAILED] Failed to mount Huge Pages File System. [FAILED] Failed to mount POSIX Message Queue File System. [FAILED] Failed to mount Kernel Debug File System. [FAILED] Failed to mount FUSE Control File System. [FAILED] Failed to mount Kernel Configuration File System. [FAILED] Failed to start Rule-based�…r for Device Events and Files. [FAILED] Failed to start Set Up Additional Binary Formats. [FAILED] Failed to start Rule-based�…r for Device Events and Files. [FAILED] Failed to start Rule-based�…r for Device Events and Files. [FAILED] Failed to start Rule-based�…r for Device Events and Files. [FAILED] Failed to start Rule-based�…r for Device Events and Files. [FAILED] Failed to start Rule-based�…r for Device Events and Files. [FAILED] Failed to start Network Time Synchronization. [FAILED] Failed to start Network Time Synchronization. [FAILED] Failed to start Network Time Synchronization. [FAILED] Failed to start Network Time Synchronization. [FAILED] Failed to start Network Time Synchronization. [FAILED] Failed to start Network Time Synchronization. [FAILED] Failed to start Network Manager. [FAILED] Failed to start Modem Manager. [FAILED] Failed to start Network Manager. [FAILED] Failed to start Remove Sta�…ext4 Metadata Check Snapshots. [FAILED] Failed to start Switcheroo Control Proxy service. [FAILED] Failed to start Power Profiles daemon. [FAILED] Failed to start Load/Save Random Seed. [FAILED] Failed to start Network Manager. [FAILED] Failed to start User Login Management. [FAILED] Failed to start Accounts Service. [FAILED] Failed to start Network Manager. [FAILED] Failed to start Power Profiles daemon. [FAILED] Failed to start Network Manager. [FAILED] Failed to start User Login Management. [FAILED] Failed to start Network Manager. [FAILED] Failed to start Power Profiles daemon. [FAILED] Failed to start User Login Management. [FAILED] Failed to start Power Profiles daemon. [FAILED] Failed to start User Login Management. [FAILED] Failed to start Power Profiles daemon. [FAILED] Failed to start User Login Management. [FAILED] Failed to start User Login Management. [FAILED] Failed to start Power Profiles daemon. I have then increased the log level to debug in the kernel cmdline to have more info: systemd.log_level=debug systemd.log_target=console and with these settings it boots normally (although much slower). I could live with it, and lower the log level once booted to have a useable system, but I would like to understand what the problem is and solve it, as it could be that on a different configuration it would fail again. Any hints, please?
Re: [systemd-devel] sd_bus_add_match callback
hi Lennart, On Fri, Apr 10, 2020 at 2:14 PM Lennart Poettering wrote: > > On Do, 09.04.20 14:12, David J (ema...@icloud.com) wrote: > > > Hello Systemd developers! > > > > > I asked this question earlier but I haven’t gotten any reply so I thought > > > asking again. > > > > > Question regarding sd_bus_add_match (sd-bus.c): > > > > > > Is there any bad consequences to use the same callback for > > > multiple signal match and then using the userdata parameter to > > > distinguish among the different signals? See the sample code below > > > for a reference of what I am trying to do. > > No sure why one would do that, but the userdata argument is something > you can use any way you like. Most people stick some context object > pointer in it, but it's entirely fine to place anything else there, > for example an enum that you cast to a pointer. If I understand correctly David's question, he wants to know if he got triggered twice on the same event in a single client. I am also interested because it could be simple for some application to be triggered by two events instead than re-firing a message internally. > > Lennart > > -- > Lennart Poettering, Berlin > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel Thank you, Giacinto ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd-bus: serving method call message in a separate thread
Hi Stanislav, On Mon, Mar 4, 2019 at 9:56 PM Stanislav Angelovič wrote: > > Hi sd-bus-ers! > > Quick question: How can I process a method call on service side in a > different thread, without creating race condition? > > Longer version: > > In sdbus-c++, we are working on server-side asynchronous method call support. > > In sd-bus, a service handles D-Bus method calls via sd_bus_message_handler_t > callback that is registered during object vtable registration. The callback > receives sd_bus_message* as the first parameter (among others), which is the > method call message. In a typical implementation, this method call is served > synchronously (D-Bus method parameters are deserialized from the message, an > operation is executed, and either method reply or method error, depending on > the condition, is sent back) and the callback returns execution to sd-bus. > Standard stuff so far. > > Now, I would like to handle the method call asynchronously, in a thread pool. > So a typical approach would be to increment ref count of sd_bus_message and > push the sd_bus_message* in a queue. It would then be popped by one of worker > threads and processed -- method parameters are deserialized, method logic is > executed, and either method reply or method error is created and sent back, > and sd_bus_message* ref count is decremented. Now, sending back the reply or > an error is thread-safe in my implementation, I don't have an issue with > that. The problem that I want to discuss is the method call sd_bus_message > instance. I cannot simply forward a pointer to it to a separate thread, > because of it's non-atomic ref count handling, which is the source of race > condition (hopefully this is the only data race condition here). It's > manipulated by both the D-Bus loop thread (which decrements ref count after > sd_bus_message_handler_t returns) and the worker thread concurrently (which > also decrements ref count after it has handled the method call). > > I see three potential solutions now: > > 1. In sd_bus_message_handler, create a deep copy of the method call > sd_bus_message via sd_bus_message_copy(). And pass a pointer to this copy to > a worker thread. This is very straight-forward and simple, it solves the race > condition, but introduces a performance cost of copying (I don't know how big > this cost is, perhaps it's rather negligible). > > 2. Don't pass the sd_bus_message* to the worker thread. In > sd_bus_message_handler, rather deserialize all arguments, create (empty) > method reply message, and move these to the worker thread. The worker thread > executes the logic and serializes results to that reply message, and sends it > back. The problem here is that we have to create a method reply or method > error before the fact (before executing method logic), which in case of > method error is impossible because we don't know possible error name and > message beforehand. > > 3. Solution on sd-bus side :-) which is to make sd_bus_message ref count > handling thread-safe (atomic), just like one for sd_bus. This avoids the need > for deep copy. What do you think? Anyway, we'd still have to come up with a > solution now, based on already releases sd-bus versions. > > So the only feasible solution for now seems to be #1 (while #3 could also be > a sd-bus improvement for the future). Do you agree that this is the good way > along the lines of sd-bus design principles, or are there more options I'm > unaware of? > In my use of sdbus I am going for option 3. Also because I am not sure what happens when sdbus writes on the bus in parallel two long messages. I know that sdbus is thread aware, but not thread safe. So 2 long messages could in theory be sent in collision. Maybe you can verify this opening two (or more) instances of a client that query automatically all introspectable methods of a specific server implemented with your thread pool, and see what happens in repeated trials. > Thank you for your constructive comments, and sorry for long elaboration :) I > wanted to be clear... > > Cheers, > Stanislav. > Cheers, Giaciinto > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd-bus delayed reply
Hi Lennart, On Mon, Jan 28, 2019 at 1:07 PM Lennart Poettering wrote: > > On Mo, 28.01.19 14:00, Jean Valjean (valjean.jean1...@gmail.com) wrote: > 65;5403;1c > > Can I, in principle, register objects and interfaces with > > sd_bus_add_object_vtable like in > > http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html > > and in handler function, take a copy, of a reference to message > > object, to global variable and use it later with > > sd_bus_reply_method_return? > > I tried to do that. But it seems, that when handler function returns, > > it sends an error message to calling client if > > sd_bus_reply_method_return > > was not called inside handler. > > Depends on what you return in the handler function: > > 1. Returning < 0 means sd-bus will generate an automatic error reply >for you, taking the returned value as negative errno (or looking >into the sd_bus_error struct passed to you, which takes >precedence). > > 2. Returning 0 means it will generate an automatic response suggesting >that the method call was not handled. > > 3. Returning > 0 means however that you handled the message, and >sd-bus will not generate any reply. I am using the same technique and works fine for methods, but I have problems with the properties: SD_BUS_WRITABLE_PROPERTY(property, signature, get_property, set_property, 0, SD_BUS_VTABLE_UNPRIVILEGED) in the file: bus-object.c, the function property_get_set_callbacks_run, executes this call to my set_property: r = invoke_property_set(bus, slot, c->vtable, m->path, c->interface, c->member, m, u, ); if (r < 0) return bus_maybe_reply_error(m, r, ); [...] r = sd_bus_send(bus, reply, NULL); with no possibility for a delayed answer. In the code above, I would need the following: if (r < 0) return bus_maybe_reply_error(m, r, ); + if (r > 0) + return 0; for it to work. Or is there another way? thank you, Giacinto > > Hence, just exit your function with "return 1" if you don't want any > automatic reply to be generated and all is good. > > (The above applies to all msg handler functions in sd-bus > basically. The reason for doing #2 is that if you install filter > functions that are called on every single incoming msg you can decide > by returning 0 or 1 whether further filter functions shall be called, > or not) > > Lennart > > -- > Lennart Poettering, Red Hat > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sd-bus parameter names
Hi Lennart, all, On Sun, Jan 6, 2019 at 6:40 PM Lennart Poettering wrote: > > On Fr, 04.01.19 09:39, Giacinto Cifelli (gciof...@gmail.com) wrote: > > > Hi, > > > > I would like to give my DBus parameters names other than the default > > arg_X for the introspection. > > > > Is it ok if I post some commits to do that, or is the feature excluded > > by choice? > > It was excluded because the data is kinda redundant and I couldn't > come up with a sexy, convincing way how to denote this in the sources. > I have submitted my change, it has been reviewed (for the form), but not taken for merge. I don't want to be pushy, just I don't know if I need to do something more. And I was expecting some comments about the sexy part. None came, so I will give myself one. DBus uses for in/out parameters a single string each, but splits them for the introspectable interface (where the names are used). sd-bus takes the first path, more functional, and then splits the parameters internally for the XML declaration. Given that, a matching way to declare parameter names is using a 'concatenated' string and splitting it at the same time as the parameters themselves. I have taken this path. > > Adding this certainly makes, if you can come up with macro syntax that > makes this nice to read. I don't know if the macro names are appealing: I just added '_WITH_NAMES' ones, following the '_WITH_OFFSET' already in place. I would like a comment also on this. > > (I'd prefer if this would use \0 or so as separator though maybe, > given it sounds weird compiling in strings that the code first has to > parse, and if \0 is used as separator then things feel more > "pre-parsed" to me) submitted so, with \0 separators. > > Anyway, by all means, please prep a patch set and submit as PR, and we > can continue discussions there!y > > Lennart > Regards, Giacinto ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] clang-format: auto-formatting the code base of systemd
Hello Sebastian, > - reformats all existing code, which requires review this can be possibly be automated, by comparing the generated precompiled files. > > Cheers, Sebastian Jennen > Regards, Giacinto ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] sd-bus parameter names
Hi,
I would like to give my DBus parameters names other than the default
arg_X for the introspection.
Is it ok if I post some commits to do that, or is the feature excluded
by choice?
The changes I would propose are:
- sd-bus-vtable.h: struct sd_bus_vtable extended like:
struct sd_bus_vtable {
/* Please do not initialize this structure directly, use the
* macros below instead */
uint8_t type:8;
uint64_t flags:56;
union {
struct {
size_t element_size;
} start;
struct {
const char *member;
const char *signature;
const char *in_names;
const char *result;
const char *out_names;
sd_bus_message_handler_t handler;
size_t offset;
} method;
struct {
const char *member;
const char *signature;
const char *out_names;
} signal;
struct {
const char *member;
const char *signature;
sd_bus_property_get_t get;
sd_bus_property_set_t set;
size_t offset;
} property;
} x;
};
The names would be separated by spaces for ease of coding. If the list
is too long, additional parameters are ignores, if too short, no name
tag is given (hence backward compatibility).
- additional macros for adding the name strings.
- processing of this additional information in bus-introspect.c,
changing the introspect_write_arguments:
static int introspect_write_arguments(struct introspect *i,
const char *signature, const char *direction, const char *names)
and related call in introspect_write_interface.
Thank you,
Regards,
Giacinto
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
