Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
If logrotate is using copytruncate, and the copy fails (for example, due to disk full), logrotate can leave behind partially written files. Unfortunately, these partially written files prevent logrotate from rotating the affected log file again, requiring manual assistance.
Version-Release number of selected component (if applicable):
logrotate-3.8.6-7.el7_2.x86_64
How reproducible:
Every time (albeit requiring a disk full or close to disk full situation)
Steps to Reproduce:
1. echo foobar > /var/log/foobar.log
2. dd if=/dev/zero of=/var/log/fill-this-disk
(wait for it to fill the disk and eventually fail)
3. logrotate -f /etc/logrotate.conf
Fails for foobar.log with:
error: error writing to /var/log/foobar.log.1: No space left on device
Actual results:
After following the steps above, logrotate cannot rotate foobar.log any longer. Even once the disk-full situation is addressed (for this example just rm /var/log/fill-this-disk), it will always fail to rotate that log file with:
error: error creating output file /var/log/foobar.log.1: File exists
Filling the whole disk via dd is just an example to force the problem to happen. It can happen naturally if the log file in question is large enough.
Expected results:
If logrotate created foobar.log.1 and could not successfully write to it, it should clean up after itself and delete it.
Additional info:
This is the config I used for foobar.log:
# cat /etc/logrotate.d/foobar
/var/log/foobar.log {
rotate 10
size 10M
create
copytruncate
}
Note that essentially the same thing happens using "delaycompress". Using the above config, remove "copytruncate" and add "compress" and "delaycompress" and follow these steps:
1. echo "foobar" > /var/log/foobar.log
2. logrotate -f /etc/logrotate.conf
3. dd if=/dev/zero of=/var/log/fill-this-disk
2. logrotate -f /etc/logrotate.conf
4. rm /var/log/fill-this-disk
# logrotate -f /etc/logrotate.conf
error: error creating output file /var/log/foobar.log.1.gz: File exists
The bug reported in https://github.com/logrotate/logrotate/issues/45 is in regards to a corrupt /var/log/logrotate.status statefile. This is somewhat different - even if the statefile is fine, logrotate won't rotate if one of its target files already exists (or clean up a target file when writing to it fails).
(In reply to David Shaw from comment #3)
> The bug reported in https://github.com/logrotate/logrotate/issues/45 is in
> regards to a corrupt /var/log/logrotate.status statefile. This is somewhat
> different - even if the statefile is fine, logrotate won't rotate if one of
> its target files already exists (or clean up a target file when writing to
> it fails).
True. This needs to be fixed, too.
(In reply to gregoire.menuel from comment #6)
> The bug seems to be corrected upstream:
> https://github.com/logrotate/logrotate/commit/
> e349752ccbbfa9ae8480ca504ded3af87e718298
Thanks for the reference! This ^^^ seems safe to be applied on el7 logrotate. It is not going to fix all the troubles one encounters while running logrotate without having any free space on the file system, but it should improve the current behavior without breaking compatibility. I am fine with backporting the above patch.
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.
https://access.redhat.com/errata/RHBA-2018:3202
Description of problem: If logrotate is using copytruncate, and the copy fails (for example, due to disk full), logrotate can leave behind partially written files. Unfortunately, these partially written files prevent logrotate from rotating the affected log file again, requiring manual assistance. Version-Release number of selected component (if applicable): logrotate-3.8.6-7.el7_2.x86_64 How reproducible: Every time (albeit requiring a disk full or close to disk full situation) Steps to Reproduce: 1. echo foobar > /var/log/foobar.log 2. dd if=/dev/zero of=/var/log/fill-this-disk (wait for it to fill the disk and eventually fail) 3. logrotate -f /etc/logrotate.conf Fails for foobar.log with: error: error writing to /var/log/foobar.log.1: No space left on device Actual results: After following the steps above, logrotate cannot rotate foobar.log any longer. Even once the disk-full situation is addressed (for this example just rm /var/log/fill-this-disk), it will always fail to rotate that log file with: error: error creating output file /var/log/foobar.log.1: File exists Filling the whole disk via dd is just an example to force the problem to happen. It can happen naturally if the log file in question is large enough. Expected results: If logrotate created foobar.log.1 and could not successfully write to it, it should clean up after itself and delete it. Additional info: This is the config I used for foobar.log: # cat /etc/logrotate.d/foobar /var/log/foobar.log { rotate 10 size 10M create copytruncate } Note that essentially the same thing happens using "delaycompress". Using the above config, remove "copytruncate" and add "compress" and "delaycompress" and follow these steps: 1. echo "foobar" > /var/log/foobar.log 2. logrotate -f /etc/logrotate.conf 3. dd if=/dev/zero of=/var/log/fill-this-disk 2. logrotate -f /etc/logrotate.conf 4. rm /var/log/fill-this-disk # logrotate -f /etc/logrotate.conf error: error creating output file /var/log/foobar.log.1.gz: File exists