Bug 60340 - Does not mail off files when rotate is set to 0
Summary: Does not mail off files when rotate is set to 0
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: logrotate (Show other bugs)
(Show other bugs)
Version: 7.1
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Elliot Lee
QA Contact: Aaron Brown
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-02-26 00:57 UTC by Charles Seraphine
Modified: 2007-04-18 16:40 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-26 00:57:34 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Charles Seraphine 2002-02-26 00:57:30 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226

Description of problem:
If "rotate 0" and "mail foo@bar" are both specified, logrotate simply deletes
the logfile without mailing it anywhere.   The expected behavior is for it to
mail the file out, but keep no archives (.1, .2, etc).

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Set rotate to 0 and the mail directive in a logrotate config file
2.Run logrotate
3.The file is rotated into the bitbucket, but not mailed off

	

Actual Results:  The file is not received at the mail destination.  It is simply
nuked.

Expected Results:  The file should indeed have been deleted, but only after
being mailed out to the specified server

Additional info:

The mail feature of logrotate is an important one, and lets the sysadmin do many
nifty log archival things.  This bug is serious because it forces at least an
extra days worth of logs to remain on the box before they can be sent off to a
collection server.

Comment 1 Elliot Lee 2002-04-15 20:13:33 UTC
I think this should be fixed in CVS...


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