Bug 1290355

Summary:	logrotate for /var/log/candlepin should work daily instead of weekly
Product:	Red Hat Satellite	Reporter:	Christian Horn <chorn>
Component:	Candlepin	Assignee:	satellite6-bugs <satellite6-bugs>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Katello QA List <katello-qa-list>
Severity:	high	Docs Contact:
Priority:	high
Version:	6.1.3	CC:	bbuckingham, bcourt, bkearney, egolov, oshtaier, sthirugn
Target Milestone:	Unspecified	Keywords:	Triaged
Target Release:	Unused
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-11-14 14:09:34 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1312478
Bug Blocks:	1296845

Description Christian Horn 2015-12-10 10:18:27 UTC

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 09:18:03 UTC

No changes in 6.1.4.  Any ideas to improve this?

Comment 3 Barnaby Court 2016-02-19 16:14:57 UTC

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 06:49:40 UTC

(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 16:43:13 UTC

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 16:55:59 UTC

Evgeni, one alternative: Would it be acceptable if the Candlepin logrotate just inherited the system default?

Comment 7 Evgeni Golov 2016-02-26 15:56:53 UTC

(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 14:09:34 UTC

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.