-
Notifications
You must be signed in to change notification settings - Fork 77
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
Bootc status without sysroot lock #585
Comments
This is currently expected, yes. I think the main fix here would be introducing a new lock for "downloading", and we drop the global sysroot lock when we're doing that. This issue however is very related to #2 in that if we were a daemon it'd be much easier to manage concurrency. |
Was just thinking about this a bit more, and maybe instead of a distinct downloading lock:
If we just did the first part of dropping the lock during fetch, then invoking in parallel in one shell (or systemd unit, etc.) a But with the resource version, after reacquiring the lock we'd detect that the world had changed, and bail; so while it'd still be racy (as it is inherently, even with global locking) it'd at least have a more obvious failure mode which I think is what we want here. |
When an automated upgrade is happening in the background, you are unable to query
bootc status
to see information about the current deployment (or to see the upgrade is in progress), since status requires a sysroot lock. I would expect such read-only commands (I can only think of status for now) to not require a system lock, and display the regular output regardless of whether another process is happening.This could cause some confusion when you're blocked from seeing information about your system due to a command that's invoked without the user saying to do so.
If there's some context I am missing or a technical limitation, I'm more than happy for you to say "this is expected" and close this.
The text was updated successfully, but these errors were encountered: