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

[Eric Yang]

Hi all,

Gerrit change for context:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/83946

Problem:
When xyz.openbmc_project.ObjectMapper stops (cleanly or due to
failure), the BMC may continue operating while the mapper is absent or
reinitializing, leading to inconsistent states across services that
rely on D-Bus path resolution.

Examples observed:
- pldmd: GetSubtree may temporarily miss MCTP EIDs, leading to removal
of sensor objects and stopping sensor polling.
- phosphor-state-manager: may fail to retrieve the correct
PowerRestorePolicy during system discovery, preventing host power-on.

Proposal:
Adopt a default policy to:
- Reboot the BMC whenever ObjectMapper stops or hits the start-rate limit.
- Refuse manual stop/restart to avoid operating without the mapper.

This can be expressed via a systemd drop-in:
[Unit]
SuccessAction=reboot
FailureAction=reboot
StartLimitAction=reboot
RefuseManualStop=yes

Questions for the community:
- Placement: Should this live as a default in phosphor-objmgr, or be a
policy in meta-phosphor?
- Stop prevention: Is RefuseManualStop acceptable?
- Safeguards: Any concerns about reboot loops if ObjectMapper cannot start?
- Reboot reason visibility: Should we emit an event log indicating
that the BMC rebooted due to ObjectMapper stopping?

Best Regards,
Eric Yang