On Tue, 10.12.13 21:27, Lukasz Skalski ([email protected]) wrote: > > On 12/10/2013 08:24 PM, Lennart Poettering wrote: > >On Wed, 04.12.13 14:44, Lukasz Skalski ([email protected]) wrote: > > > >>ENXIO, ESRCH and EADDRNOTAVAIL are also returned by > >>ioctl(KDBUS_CMD_MSG_SEND) > >>when we have unicast signal messages (signals with a DESTINATION > >>field). > > > >Well, but you cannot respond to signals. They are supposed to be these > >one-time things you send out, where no response is coming back. Method > >calls otoh are supposed to have responses where either method success or > >method failure is returned. > > Yes, I know that we cannot respond to signals, but this could be > useful for further (of course if you'll plan this kind of > functionality) messages/signals monitoring.
Hmm, printing a log_debug() message when delivery fails would certainly be a good idea. I have changed the code like that now. > For example, in GDBUS we can set G_DBUS_DEBUG variable to a list of > debug options, which cause GLib to print out different types of > debugging information. When we send unicast signal to non-exist > destination (in this example test.bus.glib) we can see: > Above error message is not visible in user application, but is very > useful for debugging purposes (we can easily check what happen with > our signal). > > IMHO it would be nice to have similar functionality in > libsystemd-bus. What is your opinion about this idea? Hmm, do you need more than the log_debug() bits I added now? Something else I'd like to see added to kdbus is that we install PID matches for messages. i.e. a way to subscribe to all messages sent by or delivered to a specific PID. This could then be used for "busctl monitor" to give it an almost "strace"-like feel, how one could watch at any time what specific processes log. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
