Searched hist:a0d7bb84 (Results 1 – 2 of 2) sorted by relevance
| /openbmc/phosphor-state-manager/ |
| H A D | scheduled_host_transition_main.cpp | a0d7bb84 Wed Mar 01 12:50:14 CST 2023 Andrew Geissler <geissonator@yahoo.com> scheduled_host_transition: change object path
Recently, it was noticed that both the
phosphor-scheduled-host-transition and phosphor-host-state-manager
services were implementing the same object on d-bus, but putting
different interfaces under them. This causes confusion because quite a
few services utilize the mapper-wait dependency:
mapper-wait@-xyz-openbmc_project-state-host%i.service
The dependency is meant to wait for the interfaces under
phosphor-host-state-manager but if the scheduled-host one starts first,
that will complete the mapper-wait dependency. This results in services
with a dependency on host-state starting before they should! It seems
the recent removal of mapper.target dependencies from the service files
has brought this bug to light.
The only other software within OpenBMC that accesses the scheduled-host
interface is in PLDM and some robot tests. If this change is approved
then I'll make the appropriate changes in those repos as we are changing
an existing d-bus object here (although a minimally used one).
Tested:
- Ensured that when xyz.openbmc_project.State.Host0 is stopped, the
"mapper wait /xyz/openbmc_project/state/host0" does not return.
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I4addb971f7ddd464c2714aa3e87ef7ef07cb737c
|
| H A D | meson.build | a0d7bb84 Wed Mar 01 12:50:14 CST 2023 Andrew Geissler <geissonator@yahoo.com> scheduled_host_transition: change object path
Recently, it was noticed that both the
phosphor-scheduled-host-transition and phosphor-host-state-manager
services were implementing the same object on d-bus, but putting
different interfaces under them. This causes confusion because quite a
few services utilize the mapper-wait dependency:
mapper-wait@-xyz-openbmc_project-state-host%i.service
The dependency is meant to wait for the interfaces under
phosphor-host-state-manager but if the scheduled-host one starts first,
that will complete the mapper-wait dependency. This results in services
with a dependency on host-state starting before they should! It seems
the recent removal of mapper.target dependencies from the service files
has brought this bug to light.
The only other software within OpenBMC that accesses the scheduled-host
interface is in PLDM and some robot tests. If this change is approved
then I'll make the appropriate changes in those repos as we are changing
an existing d-bus object here (although a minimally used one).
Tested:
- Ensured that when xyz.openbmc_project.State.Host0 is stopped, the
"mapper wait /xyz/openbmc_project/state/host0" does not return.
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I4addb971f7ddd464c2714aa3e87ef7ef07cb737c
|