<div>Hello, Ed!</div><div> </div><div>I'm not sure if my issue is relevant to what Scron discovered, but it may be.</div><div>Sometimes (not every BMC reboot) dbus get stuck during startup.</div><div>systemctl or dbus don't work (fail by timeout), services stuck trying to start, dbus-broker consumes a lot of CPU and dbus monitor shows storm of "Property Changed" events from anonymous application.</div><div>The work around I've found is to kill dbus-broker and dbus-broker-launch, then I can at least issue "reboot" without "-f", usually (8 times out of 10) BMC starts normally next time.</div><div>Unfortunately I don't know how to reproduce the issue for sure. It happens more often  when BMC has no network and doesn't have time source like NTP or date/time saved in RTC.</div><div>So I suspect calling busctl in a cycle is not the only way to get system stuck.</div><div> </div><div>Thank you!</div><div> </div><div>27.01.2021, 20:08, "Ed Tanous" <edtanous@google.com>:</div><blockquote><p>On Tue, Jan 26, 2021 at 10:34 PM Scron Chang (張仲延)<br /><<a href="mailto:Scron.Chang@quantatw.com" rel="noopener noreferrer">Scron.Chang@quantatw.com</a>> wrote:</p><blockquote><br /> Hi all,<br /><br /> I am using openbmc/entity-manager in this version: "f094125cd3bdbc8737dc8035a6e9ac252f6e8840" and I found calling Dbus makes entity-manager get stuck.<br /><br /> Reproduce this by following steps:<br /> 1. systemctl stop xyz.openbmc_project.EntityManager<br /> 2. open another terminal and do this while-loop: "while true; do busctl ; sleep 1; done"<br /> 3. systemctl start xyz.openbmc_project.EntityManager<br /> I think the root cause is this function: "nameOwnerChangedMatch." (Please refer to this line: <a href="https://github.com/openbmc/entity-manager/blob/f094125cd3bdbc8737dc8035a6e9ac252f6e8840/src/EntityManager.cpp#L1859" rel="noopener noreferrer">https://github.com/openbmc/entity-manager/blob/f094125cd3bdbc8737dc8035a6e9ac252f6e8840/src/EntityManager.cpp#L1859</a>.)</blockquote><p><br />My first thought is: Don't run an empty busctl in a loop then, but I'm<br />guessing that's not what you're really trying to do. If we had more<br />ideas about what you were really hoping to accomplish, we might have<br />some better advice for how to proceed.<br /><br />The intent of that code is to reconfigure entity-manager when<br />interfaces are changed, so if you're constantly attaching and<br />detaching to dbus, entity-manager (and object manager) never sees the<br />system as "up" and keeps waiting for the system to finish stabilizing<br />before it runs the config logic.<br /><br />In your specific case above, the code could be a little smarter, and<br />ignore unique names in that check, only caring about newly-defined<br />well known names, but without knowing your real use case, it's hard to<br />know if that would help.<br /> </p><blockquote><br /> Manually calling Dbus or calling Dbus in a script makes NameOwnerChanged signal and thus triggers the function: "propertiesChangedCallback" repeatedly. Meanwhile, the async_wait in propertiesChangedCallback gets returned because of the operation_aborted.</blockquote><p><br />Personal opinion: Don't call busctl continuously in a script. It's<br />inefficient, and causes problems like this.<br /> </p><blockquote> So here is the conclusion:<br /> Manually calling Dbus in a period that is less than 5 seconds leads entity-manager keeping to trigger new async_wait and abort the old one. However, the async_wait never gets done.<br /><br /> Is this a bug of entity-manager, or I get something wrong. Please help me with this.</blockquote><p><br />IMO, entity-manager is working as intended, but lets try to figure out<br />what you're really trying to do, and see if we can find you a<br />solution.<br /> </p><blockquote><br /> Scron Chang<br /> E-Mail <a href="mailto:Scron.Chang@quantatw.com" rel="noopener noreferrer">Scron.Chang@quantatw.com</a><br /> </blockquote></blockquote><div> </div><div> </div><div>-- </div><div>Best regards,</div><div>Konstantin Klubnichkin,</div><div>lead firmware engineer,</div><div>server hardware R&D group,</div><div>Yandex Moscow office.</div><div>tel: +7-903-510-33-33</div><div> </div>