<div>Hello!</div><div> </div><div>I've found a BMC with this issue, still can't find any difference from "normal" BMCs except of no NTP server and thus wrong time.</div><div>It looks like this:</div><div>=============================================================================</div><div><div>sig 4754.554638 6106 :1.2 <none> /org/freedesktop/systemd1/unit/obmc_2dmapper_2etarget org.freedesktop.DBus.Properties PropertiesChanged</div><div>sig 4754.554865 6107 :1.2 <none> /org/freedesktop/systemd1/unit/obmc_2dmapper_2etarget org.freedesktop.DBus.Properties PropertiesChanged</div><div>sig 4754.556711 6108 :1.2 <none> /org/freedesktop/systemd1/unit/obmc_2dmapper_2etarget org.freedesktop.DBus.Properties PropertiesChanged</div><div>sig 4754.557025 6109 :1.2 <none> /org/freedesktop/systemd1/unit/obmc_2dmapper_2etarget org.freedesktop.DBus.Properties PropertiesChanged</div><div>sig 4754.557269 6110 :1.2 <none> /org/freedesktop/systemd1/unit/obmc_2dmapper_2etarget org.freedesktop.DBus.Properties PropertiesChanged</div><div>sig 4754.557493 6111 :1.2 <none> /org/freedesktop/systemd1/unit/obmc_2dmapper_2etarget org.freedesktop.DBus.Properties PropertiesChanged</div><div>sig 4754.559039 6112 :1.2 <none> /org/freedesktop/systemd1/unit/obmc_2dmapper_2etarget org.freedesktop.DBus.Properties PropertiesChanged</div><div>sig 4754.559308 6113 :1.2 <none> /org/freedesktop/systemd1/unit/obmc_2dmapper_2etarget org.freedesktop.DBus.Properties PropertiesChanged</div><div>sig 4754.559535 6114 :1.2 <none> /org/freedesktop/systemd1/unit/obmc_2dmapper_2etarget org.freedesktop.DBus.Properties PropertiesChanged</div><div>sig 4754.571522 6115 :1.2 <none> /org/freedesktop/systemd1/unit/obmc_2dmapper_2etarget org.freedesktop.DBus.Properties PropertiesChanged</div></div><div><div>=============================================================================</div></div><div> </div><div>I've stopped dbus-monitor, the signal flow does not stop by itself.</div><div>In this conditions systemctl doesn't work.</div><div><div>{systemd} /sbin/init consumes >80% of CPU, /usr/bin/dbus-broker-launch consumes 259m of virtual memory (it seems to be normal as it also consumes a lot of memory on normal systems).</div><div> </div><div>Last second update: I've just set the time manually (date -s "2021-02-02 18:18:34") and system continued to boot.</div><div> </div></div><div> </div><div>28.01.2021, 21:39, "Ed Tanous" <<a href="mailto:edtanous@google.com" rel="noopener noreferrer">edtanous@google.com</a>>:</div><blockquote><p>On Thu, Jan 28, 2021 at 1:56 AM Konstantin Klubnichkin<br /><<a href="mailto:kitsok@yandex-team.ru" rel="noopener noreferrer">kitsok@yandex-team.ru</a>> wrote:</p><blockquote><br /> Hello, Ed!<br /><br /> I'm not sure if my issue is relevant to what Scron discovered, but it may be.<br /> Sometimes (not every BMC reboot) dbus get stuck during startup.</blockquote><p><br />That sounds slightly different, but certainly concerning.<br /> </p><blockquote> 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.</blockquote><p><br />Can you track down which anonymous application it is?<br /> </p><blockquote> 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.</blockquote><p><br />This doesn't really seem workable long term.<br /> </p><blockquote> 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.<br /> So I suspect calling busctl in a cycle is not the only way to get system stuck.</blockquote><p><br />Lets see if we can get this debugged. I know I haven't seen anything<br />similar, so I'm not sure I can be much help to you, but good luck<br />hunting it down.<br /> </p><blockquote><br /> Thank you!<br /><br /> 27.01.2021, 20:08, "Ed Tanous" <<a href="mailto:edtanous@google.com" rel="noopener noreferrer">edtanous@google.com</a>>:<br /><br /> 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:<br /><br /><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>.)<br /><br /><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 /><br /><br /><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.<br /><br /><br /> Personal opinion: Don't call busctl continuously in a script. It's<br /> inefficient, and causes problems like this.<br /><br /><br />  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.<br /><br /><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 /><br /><br /><br />  Scron Chang<br />  E-Mail <a href="mailto:Scron.Chang@quantatw.com" rel="noopener noreferrer">Scron.Chang@quantatw.com</a><br /><br /><br /><br /><br /> --<br /> Best regards,<br /> Konstantin Klubnichkin,<br /> lead firmware engineer,<br /> server hardware R&D group,<br /> Yandex Moscow office.<br /> tel: +7-903-510-33-33<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>