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.

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

Investigate and document "failure mode" #278

Open
nephros opened this issue Feb 22, 2022 · 4 comments
Open

Investigate and document "failure mode" #278

nephros opened this issue Feb 22, 2022 · 4 comments
Labels
debt fallout and other issues originating from the past

Comments

@nephros
Copy link
Contributor

nephros commented Feb 22, 2022

When PM goes into panic mode after a crash:

@nephros nephros added the debt fallout and other issues originating from the past label Feb 22, 2022
@nephros
Copy link
Contributor Author

nephros commented Feb 22, 2022

  • What is "Resolve Failure" actually doing

It simply clears the failure state and restarts the daemon.

Failure state disables automatic activation of patches on start/ boot.

https://github.com/sailfishos-patches/patchmanager/blob/master/src/bin/patchmanager-daemon/patchmanagerobject.cpp#L1899

@Olf0
Copy link
Contributor

Olf0 commented Feb 23, 2022

Yes to "Failure state disables automatic activation of patches on start/ boot.": The settings (Patchmanager only has two) are reset to their default values, AFAIK.
Additionally all Patches are deactivated.

The failure state must be manually cleared in the pulley menu (there is a new bottom-most entry there) then, which seems to start the PM-daemon.

All this is by experience, not by reading code.

@nephros
Copy link
Contributor Author

nephros commented Feb 23, 2022

Yes to "Failure state disables automatic activation of patches on start/ boot.": The settings (Patchmanager only has two) are reset to their default values, AFAIK.

As all settings are managed through the daemon (and saved to /etc/), they can not be read when the daemon is inactive.
When they can not be read, the UI shows them with their default values.

They are not reset on purpose I think, and should reappear as saved once the daemon is started. But it's possible the UI vales "win" over the saved ones in that situation.

If they do, that's a bug IMO.

@Olf0
Copy link
Contributor

Olf0 commented Feb 23, 2022

As all settings are managed through the daemon (and saved to /etc/), they can not be read when the daemon is inactive. When they can not be read, the UI shows them with their default values.

This is horrible usability: No user will comprehend that (without reading the code).
IMO they should be "grayed out" while being inaccessible, in order to indicate exactly that.

They are not reset on purpose I think, and should reappear as saved once the daemon is started. But it's possible the UI vales "win" over the saved ones in that situation.
If they do, that's a bug IMO.

I will try to check next time (still have some testing waiting for me at Codeberg), now that I know what technically happens. Although I believe to remember they do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
debt fallout and other issues originating from the past
Projects
None yet
Development

No branches or pull requests

2 participants