Resending (plain text): [DISCUSSION] Policy for handling ObjectMapper stop: reboot BMC and refuse manual stop

[Andrew Geissler]

On Wed, Oct 1, 2025 at 6:21 AM Eric Yang <eric.yang.wiwynn at gmail.com> wrote:

> Questions for the community:
> - Placement: Should this live as a default in phosphor-objmgr, or be a
> policy in meta-phosphor?

I'd be ok if it was a configurable policy. I don't think we'd enable
this on our systems. The issue is very rare but
I have seen it a few times and being able to ssh in and debug it was
very useful. Mapper is d-bus activated
so for better or worse it's going to just be restarted forever.

> - Safeguards: Any concerns about reboot loops if ObjectMapper cannot start?

Yes, this is my biggest concern. If something bad happens and a reboot
does not recover, there is no way
to debug this issue other than hoping an AC cycle fixes it. The only
thing we let automatically reboot
our systems is a kernel panic. The ramoops feature is utilized to
ensure we get debug data (and an
error log) when this occurs.

> - Reboot reason visibility: Should we emit an event log indicating
> that the BMC rebooted due to ObjectMapper stopping?

Yes, I think a log and a BMC dump after the reboot to at least get the
journal would be needed.

I also struggle with where we draw the line once we start automatic
reboots. What if
phosphor-logigng fails and nothing can log an error? What if bmcweb
crashes and there is no
external interface into the BMC?

>
> Best Regards,
> Eric Yang
>