Bug 429873 - postrotate running before "compress" finishes
postrotate running before "compress" finishes
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: logrotate (Show other bugs)
x86_64 Linux
low Severity low
: rc
: ---
Assigned To: Daniel Novotny
Depends On:
  Show dependency treegraph
Reported: 2008-01-23 10:47 EST by Chris Stankaitis
Modified: 2009-09-02 10:40 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-02 10:40:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Chris Stankaitis 2008-01-23 10:47:48 EST
Description of problem:

This seems to be a change between logrotate in RHEL4 and RHEL5.1 I have an scp 
for my httpd logrotate conf which moves the *.1.gz off box for stat processing
etc. Under RHEL4 it worked as expected, I've moved the process to a new RHEL5
server and now I am having issues with the compress arg not finishing before the
postrotate is being executed.

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


How reproducible:

intermittent, sometimes the compress will finish fast and the scp will happen
without issue, sometime the compress will run long and the postrotate will run
and send errors that there were no files to scp.

Expected results:

logrotate should wait for the compress to finish before executing the postrotate

Additional info:

Deailing with about 1GB daily apache log uncompressed to give you some
indication of why the compress may be taking a while.
Comment 1 Tomas Smetana 2008-01-24 08:37:53 EST
Are you sure that the compression finishes successfully?  Can you see the
compressed log on the original system?
Comment 2 Chris Stankaitis 2008-01-24 09:14:18 EST
Yes the Compress does finish, since I have to go back manually and move the logs
off box I have to go back and scp of the *.1.gz'ed files which are always there
Comment 3 Chris Stankaitis 2008-01-24 09:14:51 EST
is there perhaps an overall timeout in the code that is saying to finish if you
exceed X??
Comment 4 Tomas Smetana 2008-01-24 09:30:21 EST
That's why I asked.  There's fork; execvp; wait.  So until the gzip finishes
logrotate should be waiting.  I'll try to investigate the problem.  Please let
me know in case you find out any additional information.
Comment 5 Tomas Smetana 2008-01-25 07:07:32 EST
Nothing yet... Could you please attach your config file?
Comment 6 Chris Stankaitis 2008-01-25 10:03:23 EST
/var/log/httpd/*log {
    rotate 32
        /bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null` 2> /dev/null || true
    scp -i /root/.ssh/logsync.id_dsa logsync@
. 2>/dev/null || scp -i /root/.ssh/logsync.id_dsa
/var/log/httpd/*domainname.net_access_log.1 /root/webstats.sem
Comment 7 Chris Stankaitis 2008-01-25 10:04:40 EST
sorry that was the older config.. the current config is exactly the same except
it's scp'ing the *1.gz
Comment 8 Chris Stankaitis 2008-04-01 15:17:31 EDT
Hi we are still having this problem, now on other systems to where we're trying
to move off the .1.gz logfile using scp in the postrotate section.. please
advise how we can assist you in troubleshooting this issue.
Comment 9 Chris Stankaitis 2008-04-01 15:30:08 EDT
The Config:

/var/log/httpd/*log {
    rotate 62
        /bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null` 2> /dev/null || true
Comment 10 Chris Stankaitis 2008-04-01 15:32:07 EDT
The Script I am running


# couple of needed variables


# md5 the rotated *.1.gz logs.

cd /var/log/httpd
md5sum $filename > /tmp/$hostname-md5sum.txt

# Are things being touched on Admin??  if so fail, if not copy logs over

scp -i /root/.ssh/movelog.id_dsa castfirelog@admin:movelog.lock . 2>/dev/null ||
scp -q -p -i /root/.ssh/movelog.id_dsa /tmp/$hostname-md5sum.txt
/var/log/httpd/$filename /root/$hostname.sem movelog@admin:$hostname/
Comment 11 Tomas Smetana 2008-04-03 06:50:15 EDT
I should have read the documentation first...  The behaviour you're observing is
intentional.  See the bug #167575.  What confused me was the fact that the log
had been copied sometimes.  That's why I couldn't find anything in the code that
could possibly explain the issue.  It looks to be not a bug after all.
Comment 12 Tomas Smetana 2008-04-03 06:53:39 EDT
I forgot...  Please change the "postrotate" keyword for "lastaction".  It should
solve your problem.
Comment 13 Chris Stankaitis 2008-04-03 10:34:56 EDT
Okay I have changed my logrotate conf as follows.  I'll follow up tomorrow and
confirm that this has solved the issue.

/var/log/httpd/*log {
    rotate 62
        /bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null` 2> /dev/null || true
Comment 14 Chris Stankaitis 2008-04-04 11:40:05 EDT
This did not resolve the issue, can you confirm that the way I am using the last
action command is valid in Comment #13

Once again we do not have the logs copied over as they should be.  However if I
run the script manually now (Well after logrotation) it will do what it is
suppose to do.
Comment 15 Chris Stankaitis 2008-04-06 09:06:19 EDT
Using the Logrotate config from Comment #13 I get the following when I try and
run logrotate manually..

[root@static3.tor.fmpub.net ~]# logrotate -f /etc/logrotate.d/httpd
sh: line 2: lastaction: command not found

please advise
Comment 16 Tomas Smetana 2008-04-06 12:30:49 EDT
(In reply to comment #15)
> please advise

Your script should look like this:

/var/log/httpd/*log {
    rotate 62
        /bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null` 2> /dev/null || true

i.e., no postrotate, but lastaction instead.  Hope this helps.
Comment 17 Chris Stankaitis 2008-04-10 09:37:59 EDT
This still doesn't appear to be working correctly.. the only reason I have
gotten this to work is because my script now starts with a 600 second sleep.. 

Is thee any logging or debugging we can turn on with Logrotate to see why this
is not working?
Comment 18 Tomas Smetana 2008-04-10 09:48:27 EDT
You can start logrotate with -v parameter, which turns on verbose mode.  There
is also -d option that turns on the debugging mode -- i.e., only the messages
are printed but no log changes are made.
Comment 19 Tomas Smetana 2008-08-28 07:19:03 EDT
Any update on this?
Comment 20 Tomas Smetana 2009-05-15 09:43:06 EDT
I think we should close this one...  It's been in needinfo for quite a long time.
Comment 21 Daniel Novotny 2009-09-02 10:40:28 EDT
OK, closing

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