Description of problem: log rotation generates errors, and is redundant Version-Release number of selected component (if applicable): rhevm-3.1.0-50.el6ev.noarch How reproducible: Always Steps to Reproduce: 1. Install RHEVM3.1 2. Wait one day 3. Observe errors in cron job, mailed to root nightly. Actual results: Errors: ls: cannot access /var/log/ovirt-engine/engine.log.*: No such file or directory ls: cannot access /var/log/ovirt-engine/engine.log.*.gz: No such file or directory Expected results: Log gets rotated. (Better yet, use logrotate to rotate log files instead of reinventing the wheel!) Additional info: Both /etc/cron.d/ovirt-engine and /usr/share/ovirt-engine/scripts/ovirtlogrot.sh can be replaced with a single file: /etc/logrotate.d/ovirt-engine. The contents of that file should probably follow /etc/logrotate.d/ovirt-engine-dwhd, so: /var/log/ovirt-engine/engine.log { daily # or weekly, or whatever (optional) minsize 10M # (if daily/weekly is used) size 10M # (only if daily/weekly is NOT used) missingok copytruncate rotate 5 # or more compress dateext # this may or may not be desired }
Whoops, that's Red Hat *support case* # 00814500, not BZ 00814500. Is there a way to link to customer tickets?
N.B. for clues on how to use logrotate, either RTFM or see https://access.redhat.com/knowledge/solutions/1294 .
Hello Juan, I panned to do this anyway, I discover this as it uses a full directory which is not template, I did not fix it as I want to remove the cron job. What I am thinking is to remove size-rotating-file-handler and replace it with file-handler and do the rotation at jboss level, and let logrotate perform the rotation. I would like to know if I miss anything. The jasper logrotate will move to appropriate component. Thanks, Alon
I don't completely understand what you mean by "do the rotation at jboss level *and* let logrotate perform the rotation", looks contradicting to me. Rotating the logs from the application server has two important characteristics that you may want to take into account: 1. Logs are rotated without any external dependencies, like logrotate, which may be important in environments where logrotate is not available. 2. The logs are rotated exactly when needed, so if you set a limit of 1 MiB you know for sure that the log file will never be larger than 1 MiB. This is not possible with logrotate, as it runs periodically from the system crontab, once per day by default, so under certain situations the log file could end up consuming all the space in the filesystem. Number 1 is not relevant for RHEL. Number 2 is relevant, but most applications tend to ignore it.
Sorry, remove the rotation from jboss, replace the size-rotating-file-handler with file-handler. 1. logrotate exists in all environment. In these which are not, there can be a similar solution for copy-truncate. 2. Many applications still relay on external rotation as it is controlled by sysadmin and not application developer. It is a common interface which is easy to customize without knowledge of every application installed on system.... Me too prefer one rotation mechanism on my systems.
Any more comments?
Obviously, I agree with Alon (since I created the ticket in the first place!) - consistency is far more important than functionality. I manage many systems, all of which have their own quirks. The fewer application-specific exceptions I have to remember, the more successful I can be as a sysadmin. It would be even better to use syslog, and not log directly to file, for the same reason - reusing an existing, mature, generally bug-free product makes the end user's life easier. (and that way I can easily get logs into e.g. Splunk or similar tools if I need to)
*** Bug 912356 has been marked as a duplicate of this bug. ***
Need some opinion. Log rotate by default execute only once per day, on busy systems with busy logs, the administrator can setup logrotate to run per whatever interval that is required. Question: Do we want to modify the system and configure logrotate to run at higher interval by default at setup? My opinion is that we should not touch system components unless we have to, and in this case we don't. Anyone?
Speaking as a sysadmin, you should always follow the Principle of Least Surprise. In this case, I would also interpret that to mean not changing the daily cron entry for logrotate. Among other things, that will cause rpm -Va warnings because of the missing file. The exceptional case is where there are large volumes of logs, and the exceptional cases are where the admin should be getting involved... The normal case should just work. OTOH, it may be worthwhile publishing a KB article on how make logrotate run more often ("mv /etc/cron.daily/logrotate /etc/cron.hourly/")
Hello Adam, Thank you for the reply, sure we will post KB. I was thinking of creating symlink out of /etc/cron.hourly/logrotate -> ../cron.daily/logrotate, so no warning on rpm -Va, is there a real reason to move? Thanks, Alon
Without farther notes, I am going to commit the change to use log rotate and leave the system default interval of one day. Thank you, Alon
Modified per future rebase.
*** Bug 999475 has been marked as a duplicate of this bug. ***
This bug is currently attached to errata RHEA-2013:15231. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag. Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information: * Cause: What actions or circumstances cause this bug to present. * Consequence: What happens when the bug presents. * Fix: What was done to fix the bug. * Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore') Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug. For further details on the Cause, Consequence, Fix, Result format please refer to: https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes Thanks in advance.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2014-0038.html