openbmc / phosphor-state-manager

Apache License 2.0
11 stars 21 forks source link

synchronization target usage in services which are not always run as a part of the boot or shutdown #21

Open geissonator opened 2 years ago

geissonator commented 2 years ago

Ran into an architecture'ish type problem recently. There is a service, that is a part of the power off, but is also a part of the host quiesce. This service utlizes a power off synchronization target:

Wants=obmc-host-stop-pre@%i.target
Before=obmc-host-stop-pre@%i.targe

So say you power on your system, and just run this service on it's own. You actually end up starting all of the synchronization targets!

May 27 19:55:24 p10bmc systemd[1]: Reached target Stop Host0 (Pre).
May 27 19:55:24 p10bmc systemd[1]: Reached target Host0 (Stopping).
May 27 19:55:24 p10bmc systemd[1]: Reached target Host0 (Stopped).

And then, if you issue an actual power off, all of the synchronization targets have started so you have no synchronization!

The real world example we (IBM) hit this on was with the op-occ-disable@0.service. This service is called when the host goes to the Quiesce state. After Quiesce, the host-state-manager initiates a reboot of the host firmware, which starts the power off process. That power off process no longer has the synchronization targets to coordinate the power down.

I see a few potential solutions:

geissonator commented 2 years ago

Services that cause the above issue (on IBM systems):

op-occ-disable@0.service
op-stop-instructions@0.service
pldmSoftPowerOff.service
geissonator commented 2 years ago

https://gerrit.openbmc.org/c/openbmc/phosphor-state-manager/+/40026 was a commit to ensure the synchronization targets are started as a part of the primary power on and off targets. So with that change in, removing the Wants/Requires from the above services should be fine.