Bug 1290355 - logrotate for /var/log/candlepin should work daily instead of weekly
logrotate for /var/log/candlepin should work daily instead of weekly
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Candlepin (Show other bugs)
6.1.3
All All
high Severity high (vote)
: Unspecified
: --
Assigned To: satellite6-bugs
Katello QA List
: Triaged
Depends On: 1312478
Blocks: 1296845
  Show dependency treegraph
 
Reported: 2015-12-10 05:18 EST by Christian Horn
Modified: 2017-08-21 07:20 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-14 09:09:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Christian Horn 2015-12-10 05:18:27 EST
Description of problem:
/var/log/candlepin would contain ~1GB of files on this system with just 30 registered consumers and 500 clients registered via virt-who.
The logs can be compressed excellently, but logrotate is configured to only run weekly.  We should do this daily.

Version-Release number of selected component (if applicable):
sat 6.1.3
Comment 2 Christian Horn 2015-12-15 04:18:03 EST
No changes in 6.1.4.  Any ideas to improve this?
Comment 3 Barnaby Court 2016-02-19 11:14:57 EST
If you would like the log rotation to happen more frequently the /etc/logrotate.d/candlepin configuration file can be edited to whatever frequency you would like.
Comment 4 Evgeni Golov 2016-02-22 01:49:40 EST
(In reply to Barnaby Court from comment #3)
> If you would like the log rotation to happen more frequently the
> /etc/logrotate.d/candlepin configuration file can be edited to whatever
> frequency you would like.

Hi Barnaby,

sure, this is possible. The idea of this BZ was to provide a more sane default for environments bigger than just a couple of machines and to match other rotations we do daily anyways.
Comment 5 Barnaby Court 2016-02-25 11:43:13 EST
Eveni, 

Are you sure that logrotation is happening properly on the system? The size system you are referring to should not result in logs that large even with a weeks worth of data. Could this be an instance of BZ 1212955?
Comment 6 Barnaby Court 2016-02-25 11:55:59 EST
Evgeni, one alternative: Would it be acceptable if the Candlepin logrotate just inherited the system default?
Comment 7 Evgeni Golov 2016-02-26 10:56:53 EST
(In reply to Barnaby Court from comment #5)
> Are you sure that logrotation is happening properly on the system? The size
> system you are referring to should not result in logs that large even with a
> weeks worth of data. Could this be an instance of BZ 1212955?

Yes, logrotation works (after fixing the permission issue that is deployed by katello-installer and you mention in BZ 1212955).

The original problem here is that we have many hypervisors which get reported by virt-who (~600 ESXi hosts, virt-who sends updates very often, as it is event-triggered by the VMware API). Please see the attached case for the actual numbers of our deployment. This will not happen with 600 regular systems as they do not report as often as virt-who does for hypervisors.

We currently run with
  log4j.logger.org.candlepin.resource.ConsumerResource=WARN
  log4j.logger.org.candlepin.resource.HypervisorResource=WARN
in candlepin.conf, which makes the log per day shrink from 150MB to 5MB.

But our deployment would explode with the default configuration.

System default is also "weekly", so we would not actually get any better default behavior here.
Comment 10 Bryan Kearney 2016-11-14 09:09:34 EST
This is already released in 6.2, I am closing this out as Current release. This was fixed as of candlepin-0.9.54.5-1.

Note You need to log in before you can comment on or make changes to this bug.