Bug 741519 - logrotating non-empty store.log when squid is down ends with error
Summary: logrotating non-empty store.log when squid is down ends with error
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: squid
Version: 5.7
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: rc
: ---
Assignee: Pavel Šimerda (pavlix)
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-27 06:47 UTC by Jan Hutař
Modified: 2014-02-12 15:44 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-12 15:44:54 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Jan Hutař 2011-09-27 06:47:29 UTC
Description of problem:
File /etc/logrotate.d/squid contains this part which is executed only when log /var/log/squid/store.log was rotated (when it was not empty):

    postrotate
      /usr/sbin/squid -k rotate
    endscript

This command ends with non-zero exit code when squid is not running, although, if squid is not running, this rotate action is IMO not needed.


Version-Release number of selected component (if applicable):
squid-2.6.STABLE21-6.el5


How reproducible:
always


Steps to Reproduce:
1. configure squid to be operational and start it
2. # export http_proxy=http://localhost:3128/
3. # wget http://www.redhat.com
4. now /var/log/squid/store.log should not be empty
5. # service squid stop
6. # cat /tmp/tmp.PlUDY22051
rotate 40
size=1k
create
missingok
include /etc/logrotate.d
7. # logrotate -f /tmp/tmp.PlUDY22051


Actual results:
# logrotate -f /tmp/tmp.PlUDY22051
squid: ERROR: No running copy
error: error running postrotate script for /var/log/squid/store.log 
# echo $?
1


Expected results:
In case squid is not running, that postrotate script do not have sense in my opinion. Anyway, I should get 0 exit status.

Comment 1 RHEL Program Management 2011-09-27 06:57:37 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 2 Jiri Skala 2011-10-21 12:10:31 UTC
The following patch affects exit code of logrotate

--- squid.logrotate	2004-09-09 14:36:11.000000000 +0200
+++ squid.logrotate.exitcode	2011-10-21 13:49:29.341178401 +0200
@@ -26,6 +26,6 @@
 # Restarting squid is a long process and it is not worth
 # doing it just to rotate logs
     postrotate
-      /usr/sbin/squid -k rotate
+      /usr/sbin/squid -k rotate || :
     endscript
 }

But I've tested it with logrotate-3.7.9-4.fc14 (later version) and there were no issue with non-zero exit code of logrotate when `squid -k rotate` fails. So I'm going to add logrotate maintainer to CC to review this bug.

Jan, should the logrotate exit with non-zero exit code when squid exits with the code 1?

Comment 3 Jan Kaluža 2011-10-24 09:32:51 UTC
Currently it should print error message and exits with non-zero exit code. I've just tested it in F15 logrotate and also committed 2 new unit-tests into upstream repository to test this.

I've checked squid.logrotate and maybe it works properly for you in Fedora, because Fedora squid package has "sleep 1" as the last command in postrotate script, which returns zero exit code. RHEL5 package does not have that commands and therefore the exit code of postrotate script is /usr/sbin/squid exit code.

Comment 4 Jiri Skala 2011-10-24 11:18:24 UTC
Jan, thanks.

The patch in the comment #2 is correct fix. If there is no running squid `squid -k rotate` fails. Next squid start will do equivalent action.

Comment 5 Pavel Šimerda (pavlix) 2014-02-12 15:44:54 UTC
This Bugzilla has been reviewed by Red Hat and is not planned on being
addressed in Red Hat Enterprise Linux 5, and therefore will be closed.
If this bug is critical to production systems, please contact your Red
Hat support representative and provide sufficient business
justification. Issue is already fixed in RHEL-6/7.


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