Hi Mantas >>You really seem to be intent on using select() rather than an existing event >>loop or, at least, standard poll(); curious why.
There is existing code blocking on select, so it seems like the easiest way to crowbar DBus into my code. >>Also, the 'sender' field is always a bus name (not sure but I think it's >>always the unique ":1.x" name), so "sender='testsignal'," would never match >>dbus-send (or anything at all). Is there a way to “match” against “:1.x” with sd-bus i.e. instead of “testsignal”? Is it advised to match against this, or should I have the emitting program request a name? Thanks, Brian From: Mantas Mikulėnas [mailto:[email protected]] Sent: Thursday, January 7, 2016 10:36 PM To: Gorman, Brian (Vancouver) Cc: [email protected] Subject: Re: [systemd-devel] Multicast signaling with sd-bus questions On Fri, Jan 8, 2016 at 2:37 AM, Gorman, Brian (Vancouver) <[email protected]<mailto:[email protected]>> wrote: Hi all, I am in the process of considering using sd-bus to coordinate a system-wide multicast messaging system between daemons. At this time I only have resources to look into using libsystemd without system running. It seems the sd-bus documentation is very sparse compared to sd-event – does this mean sd-bus is more immature? My initial goal is to be able to select() on dbus-signals. Unfortunately my dbus experience is quite minimal, and I am not sure what this will take. Here is my initial attempt adapted from Lennarts tutorial – I have no idea if this is the right approach I was hoping if this list could perhaps provide some guidance as I suspect I am doing a few things wrong. int main(int argc, char *argv[]) { sd_bus_slot *slot = NULL; sd_bus *bus = NULL; int r; int fd; fd_set rd_fdset; int my_user_data; /* Connect to the system bus this time */ r = sd_bus_open_system(&bus); if (r < 0) { fprintf(stderr, "Failed to connect to bus: %s\n", strerror(-r)); goto finish; } r = sd_bus_request_name(bus, "Test.Me", 0); if (r < 0) { fprintf(stderr, "Failed to acquire service name: %s\n", strerror(-r)); goto finish; } r = sd_bus_add_match( bus, slot, "type='signal'," "sender='testsignal'," "interface='Japan.Reset'," "member='Test'," "path='/Japan'", my_signal_callback, my_user_data); fd = sd_bus_get_fd(bus); if (fd < 0) assert(0); FD_ZERO(&rd_fdset); FD_SET(fd, &rd_fdset); for (;;) { select(fd +1, &rd_fdset, NULL, NULL,NULL); r = sd_bus_process(bus, NULL); if (r < 0) { fprintf(stderr, "Failed to process bus: %s\n", strerror(-r)); goto finish; } } You really seem to be intent on using select() rather than an existing event loop or, at least, standard poll(); curious why. From here I was hoping to run something like “dbus-send –system –dest=Test.Me –print-reply /Japan Japan.Reset.Test string:”Hello”” You're sending a method call here, not a signal. (And signals wouldn't have a reply to --print; that's the main difference from methods.) Try `dbus-send --type=signal` or `gdbus emit`. Also, the 'sender' field is always a bus name (not sure but I think it's always the unique ":1.x" name), so "sender='testsignal'," would never match dbus-send (or anything at all). It currently get errors about DBUs complaining that Test.Me was not provided in any .service files when executing the above command. It says that because there's no connection who has claimed the "Test.Me" bus name, so dbus-daemon is trying to auto-start the apropriate daemon. On the system bus, AFAIK, the default policy only allows whitelisted names to be claimed, and usually only by root. See the various dbus-daemon config drop-ins at /etc/dbus-1/system.d/, for example. (Many of them also try to whitelist the available method calls at dbus-daemon level, although that's not required – some services check credentials manually or use polkit.) For development & debugging, you could use the session bus, which has no such restrictions. (That said, I'm not sure why sd_bus_request_name would have succeeded in that case?) -- Mantas Mikulėnas <[email protected]<mailto:[email protected]>>
_______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
