Bug 130141 - logrotate.d creates useless empty logs
logrotate.d creates useless empty logs
Status: CLOSED NEXTRELEASE
Product: Red Hat Application Server
Classification: Retired
Component: tomcat (Show other bugs)
1.0
All Linux
medium Severity low
: ---
: ---
Assigned To: Permaine Cheung
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-17 10:18 EDT by Johnathan Kupferer
Modified: 2007-04-18 13:10 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-19 11:59:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Johnathan Kupferer 2004-08-17 10:18:34 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040803

Description of problem:
/etc/logrotate.d/tomcat5 rotates Tomcat's logs and compresses them,
but it also creates a new empty log that will never be used because
the logfile names contain the date.  So the options:

/var/log/tomcat5/*.txt {
    copytruncate
    weekly
    rotate 52
    compress
    missingok
}

Should probably contain "nocreate" to override the default setting in
/etc/logrotate.conf.

Version-Release number of selected component (if applicable):
tomcat5-5.0.19-2jpp_3rh

How reproducible:
Always

Steps to Reproduce:
Let Tomcat run for a week.

Additional info:
Comment 1 Permaine Cheung 2004-08-17 16:00:33 EDT
Hi Johnathan,

According to the man pages for logrotate, with the copytruncate
directive, the create option should have no effect, as the old log
file stays in place. Is the new empty log file created by logrotate?
What files are there under /var/log/tomcat5?

Also, please upgrade to tomcat5-5.0.27-2jpp_1rh as that's what we have
for our final release.

Regards,
Permaine
Comment 2 Johnathan Kupferer 2004-08-17 22:09:48 EDT
Ah, missed that.  How about nocreate _instead_ of copytruncate?  The
issue is that tomcat logfile names contain the date so I'm ending up
with logrotate takes localhost_log.2004-08-12.txt and creates a
localhost_log.2004-08-12.txt.1.gz, but leaves a truncated file behind
with the original name.  Since tomcat rotates these filenames, there
doesn't seem to be any reason to produce the truncated files and they
just wind up cluttering the directory.

BTW, I updated to the newest tomcat5 as suggested and the issue still
exists.
Comment 3 Permaine Cheung 2004-08-19 11:59:01 EDT
I think we want to keep the new logs around, so we'll keep the create
option. New logs will be created and written to after the logs are
rotated with this logrotate configuration:

/var/log/tomcat5/*.txt /var/log/tomcat5/catalina.out {
    weekly
    rotate 52
    compress
    missingok
    sharedscripts
    postrotate
        [ -e /var/lock/subsys/tomcat5 ] && kill -USR1 `cat
/var/run/tomcat5.pid 2>/dev/null` 2>/dev/null || true
    endscript
}

I've submitted this fix upstream to jpackage.org, I'm closing this as
NEXTRELEASE.
Comment 4 Johnathan Kupferer 2004-08-19 12:26:51 EDT
I think we've been talking past each other, either that or I'm just
confused.  Sorry to keep harping on a cosmetic issue like this.  I am
now using:

/var/log/tomcat5/*.txt {
    nocreate
    weekly
    rotate 52
    compress
    missingok
}
                                                                     
                                                       
/var/log/tomcat5/catalina.out {
    copytruncate
    weekly
    rotate 52
    compress
    missingok
}

Because the original behavior seemed correct for catalina.out, just
not for the *.txt logs which already have the date embedded in the
filenames.  I'll go post this to the jpackage-discuss mailing list as
well.

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