This is an odd issue.
I was testing the chrony/ntp services on a RHEL7 VM and was resetting its time as well as the host's. Once I was satisfied with it I checked /var/log/messages
and realized it hadn't been changed in a while.
Now no matter what I do nothing is being logged except for when I restart the rsyslog service itself; when I do I get this:
Apr 15 13:59:43 mymachine1 rsyslogd: [origin software="rsyslogd" swVersion="7.4.2" x-pid="2847" x-info="http://www.rsyslog.com"] exiting on signal 2.
Apr 15 13:59:59 mymachine1 rsyslogd: [origin software="rsyslogd" swVersion="7.4.2" x-pid="2853" x-info="http://www.rsyslog.com"] start
Apr 15 14:00:11 mymachine1 rsyslogd-3000: sd_journal_get_cursor() failed: 'Cannot assign requested address'
Trying things like logger test
don't log, nothing else except rsyslog's own messages seems to. When I run rsyslog manually with -n -N1
as arguments I get:
rsyslogd: version 7.4.2, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye
It just seems like nothing can log through rsyslog for some reason. And a second identical VM on the same host (which didn't go through quite the same circle of repeatedly disabling ntp, having the date changed and rebooted multiple times) with the same rsyslog.conf file logs just fine.
At this point the date/time is correct, chrony is enabled and running, and I've rebooted several times – after 30 seconds of kernel messages nothing else gets logged again.
Thoughts?
Best Answer
Not a direct solution but I would enable some debugging to see what's happening behind the scenes.
Idea #1 - Debugging logger
For starters when you run your
logger
commands you can do them like so, echoing out messages to STDERR.Idea #2 - validate your configuration file
You can also try validating your rsyslog configuration file:
Idea #3 - Turn up rsyslogd debugging
Also I'd try enabling debugging of the
rsyslogd
daemon for further insight.Confirming version info
Confirmed bug and a workaround
The OP submitted this as a bug to Red Hat.
The bug was characterized as follows:
To which the one of the developers responded: