On 12/10/2013 09:42 PM, Lennart Poettering wrote:
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?
No, log_debug() with information that "destination isn't know" seems to
be good enough solution.
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
--
BR,
Lukasz Skalski
[email protected]
www.lukasz-skalski.com
_______________________________________________
systemd-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
