client: Explicitly systemctl start rpm-ostreed if root, dump status#2945
Merged
Conversation
Member
Author
|
Demo: |
This is a hackier an alternative to coreos#2932 that we can ship immediately because we won't block on SELinux policy. For historical reasons, the daemon ends up doing a lot of initialization before even claiming the DBus name. For example, it calls `ostree_sysroot_load()`. We also end up scanning the RPM database, and actually parse all the GPG keys in `/etc/pki/rpm-gpg` etc. This causes two related problems: - By doing all this work before claiming the bus name, we race against the (pretty low) DBus service timeout of 25s. - If something hard fails at initialization, the client can't easily see the error because it just appears in the systemd journal. The client will just see a service timeout. By explicitly using `systemctl start rpm-ostreed.service`, systemd does all of the error checking for us without involving `dbus-broker` as a middleman. Further, by using `systemctl status rpm-ostreed.service` on failure, we reuse systemd's nice rendering of the status of the unit instead of reinventing our own. This PR effectively replicates openshift/machine-config-operator#2642 in our code.
51cfe45 to
597bf93
Compare
Member
Author
|
(Added a test) |
cgwalters
added a commit
to cgwalters/machine-config-operator
that referenced
this pull request
Jul 16, 2021
This is a workaround for https://bugzilla.redhat.com/show_bug.cgi?id=1982389 which is already fixed in rpm-ostree in coreos/rpm-ostree#2995 because it will take a fair while until we can ship the fixed rpm-ostreed in RHEL and then OpenShift stable versions. (Yes, this is a sad recurring pattern) The updater client gains an explicit `Initialize` method, where we also explicitly `systemctl start rpm-ostreed` which then effectively rolls in the change from coreos/rpm-ostree#2945 too.
cgwalters
added a commit
to cgwalters/machine-config-operator
that referenced
this pull request
Feb 25, 2022
This is a workaround for https://bugzilla.redhat.com/show_bug.cgi?id=1982389 which is already fixed in rpm-ostree in coreos/rpm-ostree#2995 because it will take a fair while until we can ship the fixed rpm-ostreed in RHEL and then OpenShift stable versions. (Yes, this is a sad recurring pattern) The updater client gains an explicit `Initialize` method, where we also explicitly `systemctl start rpm-ostreed` which then effectively rolls in the change from coreos/rpm-ostree#2945 too.
cgwalters
added a commit
to cgwalters/machine-config-operator
that referenced
this pull request
Jul 8, 2022
This is a workaround for https://bugzilla.redhat.com/show_bug.cgi?id=1982389 which is already fixed in rpm-ostree in coreos/rpm-ostree#2995 because it will take a fair while until we can ship the fixed rpm-ostreed in RHEL and then OpenShift stable versions. (Yes, this is a sad recurring pattern) The updater client gains an explicit `Initialize` method, where we also explicitly `systemctl start rpm-ostreed` which then effectively rolls in the change from coreos/rpm-ostree#2945 too.
ptalgulk01
pushed a commit
to ptalgulk01/machine-config-operator
that referenced
this pull request
May 15, 2026
This is a workaround for https://bugzilla.redhat.com/show_bug.cgi?id=1982389 which is already fixed in rpm-ostree in coreos/rpm-ostree#2995 because it will take a fair while until we can ship the fixed rpm-ostreed in RHEL and then OpenShift stable versions. (Yes, this is a sad recurring pattern) The updater client gains an explicit `Initialize` method, where we also explicitly `systemctl start rpm-ostreed` which then effectively rolls in the change from coreos/rpm-ostree#2945 too.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a hackier an alternative to #2932
that we can ship immediately because we won't block on SELinux policy.
For historical reasons, the daemon ends up doing a lot of
initialization before even claiming the DBus name. For example,
it calls
ostree_sysroot_load(). We also end up scanningthe RPM database, and actually parse all the GPG keys
in
/etc/pki/rpm-gpgetc.This causes two related problems:
race against the (pretty low) DBus service timeout of 25s.
easily see the error because it just appears in the systemd
journal. The client will just see a service timeout.
By explicitly using
systemctl start rpm-ostreed.service,systemd does all of the error checking for us without involving
dbus-brokeras a middleman.Further, by using
systemctl status rpm-ostreed.serviceonfailure, we reuse systemd's nice rendering of the status
of the unit instead of reinventing our own.
This PR effectively replicates openshift/machine-config-operator#2642
in our code.