-
Notifications
You must be signed in to change notification settings - Fork 543
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
[flatpak] Predicate two cmds by gvfs service #3618
base: main
Are you sure you want to change the base?
[flatpak] Predicate two cmds by gvfs service #3618
Conversation
Two commands "flatpak --installations" and "flatpak --print-updated-env" can enable user's gvfs-daemon.service even with GVFS_REMOTE_VOLUME_MONITOR_IGNORE=1 set, so let put them under a predicate. Resolves: sosreport#3618 Relevant: RHEL-14328 Signed-off-by: Pavel Moravec <[email protected]>
2bd1ed8
to
03b61f7
Compare
Congratulations! One of the builds has completed. 🍾 You can install the built RPMs by following these steps:
Please note that the RPMs should be used only in a testing environment. |
The "Report Stage One - centos-stream-8" job (repeatedly?) fails, in the middle of avocado testing, that is weird.. I am re-running it once again. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment below, but also shouldn't this instead be considered a bug to report to flatpak?
gvfs_pred = SoSPredicate( | ||
self, cmd_outputs={ | ||
'cmd': 'systemctl --user status gvfs-daemon.service', | ||
'output': '(running)' | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SosPredicate()
supports a service
parameter to check for running services. Is that not sufficient here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about it, but I think the --user
option is crucial difference here. Let me re-test it..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As we get services list via systemctl list-unit-files --type=service
and that output does not contain users' services, InitSystem
is not aware of the service despite it is running. So service
parameter is useless here /o.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, ok, good observation. I guess that makes the question, should we expand our profiling for SystemdInit
to include user services, or just go forward with this as written and keep our SystemD abstraction in the dark about user services?
Yes, the RHEL-14328 is bug against flatpak. |
My question was more of the flavor "does it make sense for sos to make this change, when this is really a bug in flatpak that will (hopefully) be addressed and then render the predicate unnecessary?" Alternatively, do we need to version-gate this predicate? |
Two commands "flatpak --installations" and "flatpak --print-updated-env" can enable user's gvfs-daemon.service even with
GVFS_REMOTE_VOLUME_MONITOR_IGNORE=1 set, so let put them under a predicate.
Resolves: #3618
Relevant: RHEL-14328
Please place an 'X' inside each '[]' to confirm you adhere to our Contributor Guidelines