Resending (plain text): [DISCUSSION] Policy for handling ObjectMapper stop: reboot BMC and refuse manual stop
Patrick Williams
patrick at stwcx.xyz
Thu Oct 2 12:30:33 AEST 2025
On Wed, Oct 01, 2025 at 03:49:05PM -0500, Andrew Geissler wrote:
> 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.
Hmm. Don't we already have phosphor-systemd-target-monitor that
identifies critical services, collects a BMC crashdump if they fail, and
then enters a "Quiesced" state? If someone wants the BMC to restart, as
optional policy, can't they just insert that as a dependency on the
Quiesced target?
> > - 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?
I don't want to see a one-off event for "object manager crashed". I
think that it would be more reasonable to have an event for "BMC went
into Quiesced state" and the reason why, which isn't really interesting
for anyone except BMC developers, can be figured out from the
corresponding BMC crashdump.
--
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20251001/03c20ac6/attachment.sig>
More information about the openbmc
mailing list