Bug 1189082
| Summary: | tail_messages: No such file or directory: '/var/run/fedmsg/crl.pem' | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Mikolaj Izdebski <mizdebsk> |
| Component: | fedmsg | Assignee: | Ralph Bean <rbean> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 22 | CC: | bkabrda, lmacken, mizdebsk, msimacek, rbean |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-03-09 18:01:47 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Mikolaj Izdebski
2015-02-04 12:19:15 UTC
Can you provide more detail when it happened? at startup or after some time? which koschei version? on fedora cloud machine or locally? is it reproducible? Koschei just calls fedmsg's public API. It doesn't provide it any configuration, fedmsg loads it's global configration in /etc/fedmsg.d. Such error seems to be caused by misconfigured fedmsg, which is outside of koschei's scope. I just tried it with default configuration that's in fedora 21 and it seems to work properly. (In reply to Michael Simacek from comment #1) > Can you provide more detail when it happened? > at startup or after some time? After some time koschei-watcher.service just died. > which koschei version? > on fedora cloud machine or locally? It was in production on koschei.cloud.fedoraproject.org. I think it was latest upstream version. > is it reproducible? No, I didn't see it again. I found the problem in fedmsg, reassingnig. Description of the problem: In fedmsg.crypt._load_remote_certs, when there is a network failure and the certificate hasn't been downloaded yet, it ignores the error and returns the path as if it was there. This causes the failure later, because the file doesn't exist and raises IOError. IOErrors cannot be reliably handled by the client application, because it has no idea what kind of error it is, therefore cannot simply restart itself. Expected result: If there is a network error and there's no cached version of a certificate, it should raise more specific exception, so that the application can determine it was a network failure and act appropriately. Additional question: If it's been running for longer time as the original report says, why there wasn't a cached file already? How about this for a solution? Have fedmsg re-raise the original `requests.exceptions.ConnectionError` during the call to `fedmsg.crypto.validate(msg, **config)`:
diff --git a/fedmsg/crypto/x509.py b/fedmsg/crypto/x509.py
index f15f183..4d02f5f 100644
--- a/fedmsg/crypto/x509.py
+++ b/fedmsg/crypto/x509.py
@@ -246,7 +246,8 @@ def _load_remote_cert(location, cache, cache_expiry, **config):
with open(cache, 'w') as f:
f.write(response.content)
except requests.exceptions.ConnectionError:
- log.warn("Could not access %r" % location)
+ log.error("Could not access %r" % location)
+ raise
except IOError as e:
# If we couldn't write to the specified cache location, try a
# similar place but inside our home directory instead.
I'll wait for feedback before committing and preparing a release.
(In reply to Ralph Bean from comment #4) > How about this for a solution? Have fedmsg re-raise the original > `requests.exceptions.ConnectionError` during the call to > `fedmsg.crypto.validate(msg, **config) ConnectionError should be fine. > > > diff --git a/fedmsg/crypto/x509.py b/fedmsg/crypto/x509.py > index f15f183..4d02f5f 100644 > --- a/fedmsg/crypto/x509.py > +++ b/fedmsg/crypto/x509.py > @@ -246,7 +246,8 @@ def _load_remote_cert(location, cache, cache_expiry, > **config): > with open(cache, 'w') as f: > f.write(response.content) > except requests.exceptions.ConnectionError: > - log.warn("Could not access %r" % location) > + log.error("Could not access %r" % location) > + raise > except IOError as e: > # If we couldn't write to the specified cache location, try a > # similar place but inside our home directory instead. > > > I'll wait for feedback before committing and preparing a release. fedmsg-0.12.0-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/fedmsg-0.12.0-1.fc21 fedmsg-0.12.0-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/fedmsg-0.12.0-1.fc20 fedmsg-0.12.0-1.el7 has been submitted as an update for Fedora EPEL 7. https://admin.fedoraproject.org/updates/fedmsg-0.12.0-1.el7 fedmsg-0.12.0-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/fedmsg-0.12.0-1.el6 And.. it's in the infra repo now, too. fedmsg-0.12.1-1.el7 has been submitted as an update for Fedora EPEL 7. https://admin.fedoraproject.org/updates/fedmsg-0.12.1-1.el7 fedmsg-0.12.1-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/fedmsg-0.12.1-1.el6 fedmsg-0.12.1-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/fedmsg-0.12.1-1.fc21 fedmsg-0.12.1-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/fedmsg-0.12.1-1.fc20 fedmsg-0.12.2-1.el7 has been submitted as an update for Fedora EPEL 7. https://admin.fedoraproject.org/updates/fedmsg-0.12.2-1.el7 fedmsg-0.12.2-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/fedmsg-0.12.2-1.el6 This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22 fedmsg-0.12.2-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report. fedmsg-0.12.2-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report. fedmsg-0.12.1-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report. fedmsg-0.12.1-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report. |