Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

synchronization target conflicts not working as expected #16

Open
geissonator opened this issue Aug 13, 2021 · 2 comments
Open

synchronization target conflicts not working as expected #16

geissonator opened this issue Aug 13, 2021 · 2 comments

Comments

@geissonator
Copy link
Contributor

Seeing intermittent issues where the synchronization target, [email protected] is not stopping like it should with the system is powered off.

# systemctl status obmc-power-start-pre\@0.target 
 [email protected] - Power0 On (Pre)
     Loaded: loaded (/lib/systemd/system/[email protected]; static)
     Active: active since Fri 2021-08-13 03:06:58 UTC; 16h ago

Aug 13 03:06:58 p10bmc systemd[1]: Reached target Power0 On (Pre).


# systemctl status obmc-chassis-poweroff\@0.target 
 [email protected] - Chassis0 (Power Off)
     Loaded: loaded (/lib/systemd/system/[email protected]; static)
     Active: active since Fri 2021-08-13 03:34:56 UTC; 16h ago

Aug 13 03:34:56 p10bmc systemd[1]: Reached target Chassis0 (Power Off).

Another synchronization target correctly stopped that conflicts with teh same target:

# systemctl status obmc-power-start\@0.target   
 [email protected] - Power0 On (Starting)
     Loaded: loaded (/lib/systemd/system/[email protected]; static)
     Active: inactive (dead) since Fri 2021-08-13 03:34:48 UTC; 16h ago

Aug 13 03:23:06 p10bmc systemd[1]: Reached target Power0 On (Starting).
Aug 13 03:34:48 p10bmc systemd[1]: Stopped target Power0 On (Starting).
@geissonator
Copy link
Contributor Author

The only major difference between the working and non-working target is this is in the non-working:

Wants=mapper-subtree-remove@-xyz-openbmc\x5fproject-software\x3Axyz.openbmc_project.Software.ActivationBlocksTransition.service
After=mapper-subtree-remove@-xyz-openbmc\x5fproject-software\x3Axyz.openbmc_project.Software.ActivationBlocksTransition.service
Wants=mapper-subtree-remove@-xyz-openbmc\x5fproject-logging\x3Axyz.openbmc_project.Logging.ErrorBlocksTransition.service
After=mapper-subtree-remove@-xyz-openbmc\x5fproject-logging\x3Axyz.openbmc_project.Logging.ErrorBlocksTransition.service

My hunch at this point is that our somewhat unorthodox use of Wants/After using mapper is causing a bug of some sort in systemd. Looking at the journal, I see those services starting and running as expected, even in the error scenarios, so nothing obvious yet.

@geissonator
Copy link
Contributor Author

Workaround put in https://gerrit.openbmc-project.xyz/c/openbmc/phosphor-power/+/45893, remove once this issue figured out.

bradbishop pushed a commit to openbmc/phosphor-power that referenced this issue Aug 13, 2021
@geissonator
reg-config: ensure runs before chassis power on
bb1dfb6 
openbmc/phosphor-state-manager#16 documents an issue with the
[email protected]. Root cause is unknown at this point. Until
root cause is understood there, set the service dependency directly to
ensure this service always runs prior to chassis power being turned on.

Tested:
- Ran 10 power on/off and verified this service always ran before power
  was turned on to the chassis.

Change-Id: I6192d8226f6916ba36b01407f271215bd53c2ab3
Signed-off-by: Andrew Geissler <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@geissonator