Hide Forgot
Description of problem: With immark.so configured and loaded, rsyslogd does not put mark messages in /var/log/messages. Version-Release number of selected component (if applicable): 5.8.2 How reproducible: Since F15, always. Steps to Reproduce: 1. Enable immark.so module in /etc/rsyslog.conf 2. 3. Actual results: Marks are not recorded, ever. Expected results: Marks should be recorded after 20 minutes of inactivity in the log file, I assume. Or, perhaps after MarkMessagePeriod of inactivity on any action file, it's not really clear. Additional info: immarks module isn't even documented. Some references are scattered around in the extra documentation, but on the page where all the modules are listed, there is no link for immark.
(In reply to comment #0) > With immark.so configured and loaded, rsyslogd does not put mark messages in > /var/log/messages. What is actually your configuration? I suppose you've just uncommented this line: $ModLoad imudp.so > Actual results: > Marks are not recorded, ever. > > Expected results: > Marks should be recorded after 20 minutes of inactivity in the log file, I > assume. Or, perhaps after MarkMessagePeriod of inactivity on any action file, > it's not really clear. I think this correct, but after some brief testing this doesn't seem to work. I've also tried using the 'ActionWriteAllMarkMessages' directive and in this case the mark messages appeared, so perhaps it can be used as a workaround.
Hi, Tomas. Thanks for your help. Yes, I just un-commended that line. That's what I've been doing since rsyslogd became the new syslog daemon, whenever that was. My config file looks like this: ... #### MODULES #### $ModLoad imuxsock # provides support for local system logging (e.g. via logger command) $ModLoad imklog # provides kernel logging support (previously done by rklogd) # PRD allow marks $ModLoad immark # provides --MARK-- message capability $MarkMessagePeriod 600 # reduce mark interval to 10 minutes (default 1200 sec) ... # Log anything (except mail) of level info or higher. # Don't log private authentication messages! *.info;mail.none;authpriv.none;cron.none /var/log/messages ... I will try the workaround. But, to that end, I must report further problems: 1) rsyslogd doesn't seem to act on HUP as documented. (It actually logs "rsyslogd was HUPed", but the config file is not re-loaded.) 2) The PID file documented is /var/run/rsyslogd.pid, but this is wrong, the correct PID file is /var/run/syslogd.pid 3) systemctl reload rsyslogd.service is not implemented, which I take to be the current canonical method for reloading configuration files for all services. Not that I'm really worried about loosing messages on my desktop system during a restart, but these issues are very surprising, to say the least.
(In reply to comment #2) > I will try the workaround. But, to that end, I must report further problems: > > 1) rsyslogd doesn't seem to act on HUP as documented. (It actually logs > "rsyslogd was HUPed", but the config file is not re-loaded.) Since rsyslog v5 the daemon closes and reopens all logfiles upon receiving SIGHUP. To reload configuration you have to restart the daemon. > 2) The PID file documented is /var/run/rsyslogd.pid, but this is wrong, the > correct PID file is /var/run/syslogd.pid This is a divergence from upstream to support coexistence of rsyslog and syslog-ng. > 3) systemctl reload rsyslogd.service is not implemented, which I take to be the > current canonical method for reloading configuration files for all services. As noted earlier, the current version of rsyslog doesn't support a 'reload' operation, you have to do a full restart instead. For reference, see http://blog.gerhards.net/2008/10/new-rsyslog-hup-processing.html
I see. Thanks for explaining, that all makes sense. I saw the section on SIGHUP, but I didn't read to the end of the paragraph. Sure, enough. Not that I disagree with the decision, but that was a shock. It's just been a reliable feature since...well, before 1995, anyway. BTW, the workaround seems to work for me. Thanks for looking into the bug, though, too.
Fixed upstream since rsyslog-5.8.5.