Rudder

First off - thank you very much for the New Year post card which I received just recently - this is so sweet of you!
Sorry if this is inappropriate place - I just do not know where else to write to all of you :)

I have noticed a couple of issues related to the subject.

First off, for rsyslog-based log files (I am speaking of RHEL, don't know about the others) new files have been created but relevant applications evidently continued to write into the old files. This is caused by improper postrotate script. Currently it uses

/etc/init.d/httpd reload > /dev/null

However, at least on my CentOS 6.5 box the reload option for that script merely exits with status code 3. There is a force-reload option, which essentially does a full daemon restart. The rsyslog documentation shipped with the stock package discusses the problem at hand, and the bottom line is that the full restart is quite expensive and is not recommended for log rotation purposes. It is suggested to use HUP signal, so the postrotate block should do something like

killall -HUP rsyslogd

I just have checked the stock rsyslog packages on CentOS5 - there are two versions, rsyslog (v3) and rslyslog5. The latter would have exactly the same issues that the one on CentOS6; rsyslog v3 actually has the reload option to the init script, but a closer look reveals that it does signalling too, just in a more sophisticated fashion, so the suggested above killall would also do.

Another problem is secondary to the previous - if the new files are created but never written to, the "notifemtpy" option sort of guarantees that proper rotation will never be attempted again - this will lead the system to run out of space, eventually. I would suggest dropping that option.

And the last issue is with non-compliant-reports.log - very similar to the above - the new file created but not switched to - but it is not an rsyslog-driven and there is no postrotate action. Which application (if any) and how needs to be prompted to switch to the new file? Also, the file /var/log/rudder/core/rudder-webapp.log may be the subject to the same issue, but it is written only once a day, and I do not want to restart the program, as restarting it would switch to the new file for sure, but I would lose the ability to confirm that the switch actually happened today.