Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 8110 - fix for bug 7074 not quite correct: postrotate still errors
Summary: fix for bug 7074 not quite correct: postrotate still errors
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: apache
Version: 6.1
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Preston Brown
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-01-02 16:08 UTC by cobbe
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-01-13 02:36:15 UTC


Attachments (Terms of Use)

Description cobbe 2000-01-02 16:08:01 UTC
See bug 7074 for details of the original problem.  The updated logrotate
config file included with apache 1.3.9-8 gets closer, but doesn't quite fix
the problem.  Now, the error mailed to root reads:

errors occured while rotating /var/log/httpd/access_log

error running postrotate script

I think this is happening because, even though killall's error message is
thrown away rather than being mailed to root, killall still exits with a
non-zero return code, and this makes logrotate think there was an error.

Quick solution: replace

/usr/bin/killall -HUP httpd 2> /dev/null

with

/usr/bin/killall -HUP httpd 2> /dev/null | true

It looks to me as if the only reason killall can return a non-zero code is
that it failed to find a process matching the supplied name.  If this is
true, then the above code will be fine.  If, however, I'm missing an error
condition, I'd use the real solution below.  (I'd personally go with the
real solution, just because I'm used to having to code defensively.)

Real solution: do some checking, probably using pidof, to determine
if httpd is running, and THEN kill it as appropriate.  That way, any other
errors produced by killall will be taken into account and reported.

For bash/bash2, something like the following, perhaps.

apache_pid=`/sbin/pidof httpd`
if [ $? ] ; then
	/usr/bin/kill -HUP $apache_pid

or whatever.  This has not been tested.

Comment 1 Richard Cobbe 2000-01-04 20:04:59 UTC
(Me again, just from a different email address.)

Well, actually, my quick fix above will work, but I actually meant

/usr/bin/killall -HUP httpd 2> /dev/null || true

(logical OR, not pipe....<sigh>)

Comment 2 Preston Brown 2000-01-13 02:36:59 UTC
changed for 6.2

Comment 3 James Ralston 2000-02-14 19:09:59 UTC
I'm not sure how this issue was specifically resolved, but IMHO, probably the
cleanest way to invoke the killall in /etc/logrotate.d/apache is to do this:

if /sbin/chkconfig httpd; then
  /usr/bin/killall -HUP httpd
else
  true
fi

This way, if apache isn't supposed to be running in the current runlevel
(according to chkconfig), nothing will occur, but the return value of the check
will still be 0 (true), so logrotate won't see anything amiss.  But if apache is
supposed to be running, and killall fails (because apache wasn't running,
perhaps), then the return value will be 1 (false), so an error will be reported
(emailed).


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