Sd_bus_call - ELOOP Issue

Vernon Mauery vernon.mauery at linux.intel.com
Sat May 30 04:21:07 AEST 2020


On 29-May-2020 01:07 PM, Patrick Williams wrote:
>On Fri, May 29, 2020 at 09:29:48PM +0530, Kumar Thangavel wrote:
>
>>        6. As per our understanding, current  sd_bus_call not supported for
>> connection with the same bus/clients. (sender  and receiver are same
>>            application name ). Please confirm.
>>
>>             Log :
>>             yosemitev2 ipmid[370]: sd_bus_call function called..
>>             yosemitev2 ipmid[370]: sd_bus_call function ELOOP .
>>             yosemitev2 ipmid[370]:  unique name = :1.71
>>             yosemitev2 ipmid[370]:  incoming sender = :1.71
>>             yosemitev2 ipmid[370]: executeCallback called. catch block
>>             yosemitev2 ipmid[370]: EXCEPTION=sd_bus_call:
>> System.Error.ELOOP: Too many levels of symbolic links
>
>Yes, it appears that systemd has some code to specifically return ELOOP
>in this case:
>
>https://github.com/systemd/systemd/blob/master/src/libsystemd/sd-bus/sd-bus.c#L2236
>
>>
>>        So,  Could you please confirm sd_bus_call does not support the same
>> bus/clients with in the same process.
>>
>>        Also, Please let us know if any alternate method to  call the
>> execute dbus method with the same bus/connection.
>
>My suggestion would be to see if one of the functions in ipmid-new.cpp,
>such as executeIpmiCommand, can be exposed to providers for these kind
>of recursive callbacks.
>
>Maintainers of phosphor-host-ipmid have opinions here?

ipmid hosts a very small set of D-Bus objects/interfaces. I don't know 
of any standard commands that would call back to itself though. There is 
some context I seem to be missing here.

--Vernon


More information about the openbmc mailing list