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