phillxnet
commented
1 year ago @kanecko Thanks for the report, however this issue is kind of a non-issue as it is inevitable that at times our zypper calls will clash with the normal system scheduled calls, or our own possible. And this event is logged and silently fails.
But lets leave this issue open as a more elegant solution might be to first check for existing zypper activity before we make any of our own zypper calls; or further calls of our own for that matter.
The particular page refresh is not relevant here, it's our header related calls most likely. I.e. the flashing 'updates available' icon to the left of kernel info is informed by these zypper calls.
Thanks for opening the issue, quite timely actually as I saw a similar event the other day on rapidly enabling Testing while the initial boot-up zypper was still running, resulting int the Rockstor-Testing channel not then being enabled, however a re-visit to the updates page later resolved this silently as it re-asserted from database entries the system state requested by the first silently failed Testing channel addition.
Likely what we need is to catch this 'Close this application before trying again.' zypper return and re-interpret to a 'zypper busy' or "System Packaging busy" or whatever header indicator or the like. We could also use this same signal to avoid spamming zypper ourselves ,such as you have observed here most likely.
When refreshing the Disks page too rapidly, this error will appear in rockstor.log:
[25/Jan/2023 11:15:47] ERROR [system.osi:225] non-zero code(7) returned by command: ['/usr/bin/zypper', '--non-interactive', '-q', 'list-updates']. output: [''] error: ['System management is locked by the application with pid 14689 (/usr/bin/zypper).', 'Close this application before trying again.', '']