meta-facebook: yosemite4: Fix chassis-powercycle self-kill via Conflicts

Remove bidirectional `Conflicts=` from chassis-powercycle@.service and
replace with unidirectional `ExecStartPre=-/bin/systemctl stop
log-chassis-powercycle-sel@%i.service`, so that chassis-powercycle can
stop stale log-sel when a new cycle starts, but log-sel can never kill
chassis-powercycle. Also use --no-block for the in-script restart of
log-sel, which declares After=chassis-powercycle and cannot start until
the caller exits.

Motivation:
[1] added `Conflicts=log-chassis-powercycle-sel` to stop stale log-sel
when a new power cycle starts. However, `Conflicts=` is bidirectional:
starting log-sel also terminates chassis-powercycle. [2] simplified the
lock release by removing the SIGTERM trap. [3] added `systemctl restart
log-chassis-powercycle-sel` inside the chassis-powercycle script.

With [2] and [3] together, restarting log-sel mid-script triggers
bidirectional Conflicts=, killing the running chassis-powercycle. The
lock_cleanup subshell is terminated before decrementing the concurrency
counter, leaking it permanently and blocking all subsequent slots.
Observed in 8-slot concurrent AC cycle: only 2-3 slots complete, the
rest hang forever.

Reference:
[1] https://gerrit.openbmc.org/c/openbmc/openbmc/+/89790
[2] https://gerrit.openbmc.org/c/openbmc/openbmc/+/90501
[3] https://gerrit.openbmc.org/c/openbmc/openbmc/+/90532

Tested:
On Yosemite 4, ran 8-slot concurrent blade chassis power cycle
124 rounds. Verified slots 1-8 each produce the following SEL entries in
order, with none missing or extra:
  "Execute chassis%i AC power cycle"
  "Host%i state is off"
  "Execute host%i DC power on"
  "Host%i system DC power is on"
  "Host%i state is on"
  "Chassis%i AC power cycle success"

Change-Id: I30409a64cd6c74f87de2fc82c45cdfa68efffeda
Signed-off-by: Eric Yang <eric.yang.wiwynn@gmail.com>

0 files changed, 0 insertions, 0 deletions