[systemd-devel] [PATCH] libsystemd-bus: Add return error msg for unicast signals when well-known name is not available

[Lukasz Skalski]

On 12/10/2013 09:42 PM, Lennart Poettering wrote:
> On Tue, 10.12.13 21:27, Lukasz Skalski (lukasz.skalski at op.pl) wrote:
>
>>
>> On 12/10/2013 08:24 PM, Lennart Poettering wrote:
>>> On Wed, 04.12.13 14:44, Lukasz Skalski (l.skalski at partner.samsung.com) 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
lukasz.skalski at op.pl
www.lukasz-skalski.com