patchmanager icon indicating copy to clipboard operation
patchmanager copied to clipboard

Investigate and document "failure mode"

Open nephros opened this issue 3 years ago • 4 comments

When PM goes into panic mode after a crash:

  • What is "Resolve Failure" actually doing
  • What should it be doing
  • How can it be improved (e.g. by loading a state saved through #277)

nephros avatar Feb 22 '22 11:02 nephros

  • 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

nephros avatar Feb 22 '22 11:02 nephros

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.

Olf0 avatar Feb 23 '22 00:02 Olf0

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.

nephros avatar Feb 23 '22 09:02 nephros

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.

Olf0 avatar Feb 23 '22 13:02 Olf0