Bug 974691
Summary: | Since cleaning up from #974132, nothing gets written to /var/log/messages | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> |
Component: | rsyslog | Assignee: | Tomas Heinrich <theinric> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 19 | CC: | mah.darade, pvrabec, robatino, theinric |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | RejectedBlocker RejectedFreezeException | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-06-25 09:35:11 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
Adam Williamson
2013-06-14 20:11:38 UTC
Proposing as a final blocker. It may turn out that this is some idiosyncracy I've caused with my cleanup, but if it affects all systems with systemd -8 and rsyslog 7.4.0, it'd violate: https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria#System_logging "A system logging infrastructure must be available, enabled by default, and working." note one of the notes reads "This must be done in accordance with relevant standards accepted by the Fedora Project." - I believe we still ought to be writing /var/log/messages to comply with this. Two guesses: - the state file holding the journal cursor might be completely off after erasing /var/log/journal/* - the lines about missed messages refer to the systemd provided syslog.service + syslog.socket Try erasing the state file - /var/lib/rsyslog/imjournal.state Try getting the state of the syslog.socket ; maybe it got started and the socket is now full. Inspect the condition of the (r)syslog service file ; maybe it got modified and wasn't updated. Discussed at 2013-06-17 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-17/f19final-blocker-review-6.2013-06-17-16.01.log.txt . As per http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.html#VARLOGLOGFILESANDDIRECTORIES , FHS does require /var/log/messages be present (and so our criteria imply that it should be correctly populated) if syslogd is installed, so if this truly affected all installations, there is an argument for it to be a blocker bug. For now, we don't know that it does. So we are delaying the decision and we will test with fresh TC4 installations once TC4 is available, to determine if this is a general problem or not. Tomas, thanks for the tips, I'll look into my system ASAP. Discussed at 2013-06-19 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-19/f19final-blocker-review-7.2013-06-19-16.01.log.txt . I don't have the constant failures any more since Jun 17 - looks like it somehow cleared up after that date, but not sure why yet. Others report that they have a single "Forwarding to syslog missed XX messages." line per boot, indicating there is some kind of problem with forwarding some messages early in each boot, but no-one else sees the more serious issue of it constantly failing to forward almost anything. Given this data we agreed to reject this as a blocker and freeze exception issue for now. I'll still try and find some time to look into it a bit further and check it's not more serious than it sounds. Sorry I didn't yet get the data requested, Tomas. (In reply to Adam Williamson from comment #4) > I don't have the constant > failures any more since Jun 17 - looks like it somehow cleared up after that > date, but not sure why yet. Others report that they have a single > "Forwarding to syslog missed XX messages." line per boot, indicating there > is some kind of problem with forwarding some messages early in each boot, > but no-one else sees the more serious issue of it constantly failing to > forward almost anything. For quite some time, systemd forced rsyslog to read from /run/systemd/journal/syslog instead of /dev/log. rsyslog doesn't use this socket since rsyslog-7.4.0-1 and doesn't pose as a syslog.service. I'd expect the messages to be related to this socket interface; maybe the socket filled up and journal has started to drop messages. Since rsyslog doesn't use it anymore, this might be a fallout of the recent carnage or a problem in journal's flow control or an issue in the rsyslog-systemd plumbing. I think this can be closed after a year of silence. sorry about that, I never quite got around to poking this again, and then things moved on :/ Don't worry about it. It might have been fixed in the meantime and if not, somebody will let us know. :] |