[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 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.

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:

========================================================================
GDBus-debug:Message:
   >>>> SENT D-Bus message (112 bytes)
   Type:    signal
   Flags:   no-reply-expected
   Version: 0
   Serial:  2
   Headers:
     path -> objectpath '/test/bus/glib'
     interface -> 'test.bus.glib'
     member -> 'SampleSignal'
     destination -> 'test.bus.glib'
   Body: ()

========================================================================
GDBus-debug:Message:
   <<<< RECEIVED D-Bus message (202 bytes)
   Type:    error
   Flags:   no-reply-expected
   Version: 0
   Serial:  3
   Headers:
     error-name -> 'org.freedesktop.DBus.Error.ServiceUnknown'
     reply-serial -> uint32 2
     destination -> ':1.66'
     sender -> 'org.freedesktop.DBus'
     signature -> signature 's'
   Body: ('The name test.bus.glib was not provided by any .service files',)

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?

P.S. Of course my previously patch isn't complete at this moment, it's 
the starting point to implement something similar.

>
> The code in question will generate an error reply for method calls on
> failure, but simply eat up the error when sending a signal fails. Which
> is the right thing to do...
>
>> ---
>>   src/libsystemd-bus/bus-kernel.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/libsystemd-bus/bus-kernel.c b/src/libsystemd-bus/bus-kernel.c
>> index b85a10d..1499830 100644
>> --- a/src/libsystemd-bus/bus-kernel.c
>> +++ b/src/libsystemd-bus/bus-kernel.c
>> @@ -414,7 +414,7 @@ int bus_kernel_write_message(sd_bus *bus, sd_bus_message *m) {
>>                           /* ENXIO: unique name not known
>>                            * ESRCH: well-known name not known */
>>
>> -                        if (m->header->type == SD_BUS_MESSAGE_METHOD_CALL)
>> +                        if (m->header->type == SD_BUS_MESSAGE_METHOD_CALL || m->header->type == SD_BUS_MESSAGE_SIGNAL)
>>                                   sd_bus_error_setf(&error, SD_BUS_ERROR_SERVICE_UNKNOWN, "Destination %s not known", m->destination);
>>                           else
>>                                   return 0;
>> @@ -423,7 +423,7 @@ int bus_kernel_write_message(sd_bus *bus, sd_bus_message *m) {
>>
>>                           /* EADDRNOTAVAIL: activation is possible, but turned off in request flags */
>>
>> -                        if (m->header->type == SD_BUS_MESSAGE_METHOD_CALL)
>> +                        if (m->header->type == SD_BUS_MESSAGE_METHOD_CALL || m->header->type == SD_BUS_MESSAGE_SIGNAL)
>>                                   sd_bus_error_setf(&error, SD_BUS_ERROR_SERVICE_UNKNOWN, "Activation of %s not requested", m->destination);
>>                           else
>>                                   return 0;
>
>
> Lennart
>

-- 
BR,
Lukasz Skalski
lukasz.skalski at op.pl
www.lukasz-skalski.com
https://plus.google.com/+LukaszSkalski