webignition

Well-Known Member
Jan 22, 2005
1,876
1
166
I've tried as best as I can to educate myself to sort this problem out, however I just can't find out why this is happening (I simply don't know enough). I'm hoping that if I explain the problem, someone will be able to suggest where I can start troubleshooting the issue - I'm perfectly capable of following instructions and learning from them, however without the initial knowledge I'm a bit stuck!

An email was sent to root this morning containing the following:
Code:
/etc/cron.daily/logrotate:

error: error running postrotate script
error: error running postrotate script
error: error running postrotate script
error: error running postrotate script
error: error running postrotate script
error: error running shared postrotate script for /var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron
The same happened last week and so I'm starting to get a bit concerned!

Obviously this seems to be a problem with the weekly log rotation, as this has now occured twice, separated by one week.

I don't know what logs get rotated on a weekly basis, however I've taken a peek at what has or hasn't been rotated and noticed that the Exim logs seem to have rotated correctly (/var/log/exim_mainlog, /var/log/exim_paniclog and /var/log/exim_rejectlog) as they are all relatively small and have been modified recently.

However the following logs are of zero size, created around 5AM (which is when the above email was sent):

/var/log/maillog
/var/log/messages
/var/log/secure

and the following logs are still being added to instead of the above logs:

/var/log/maillog.1
/var/log/messages.1
/var/log/secure.1

Trying to force logrotate manually by running:

Code:
logrotate /etc/logrotate.conf -f
produces the same errors.

The contents of /etc/logrotate.conf (which I have steered well away from modifiying) is:

Code:
# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# uncomment this if you want your log files compressed
#compress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp -- we'll rotate them here
/var/log/wtmp {
    monthly
    create 0664 root utmp
    rotate 1
}

# system-specific logs may be also be configured here.
Any suggestions as to where I may begin to troubleshoot this issue would be greatly appreciated!

--
Jon
 

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,437
33
473
Go on, have a guess
Run logrotate like this and work through it until you find the errors:

/usr/sbin/logrotate -vf /etc/logrotate.conf
 

webignition

Well-Known Member
Jan 22, 2005
1,876
1
166
Having looked into things further . . .

I gave /usr/sbin/logrotate -vf /etc/logrotate.conf a shot and looked through the output.

I've figured out that the contents of the files in /etc/logrotate.d are included in logrotate.conf and so have a look at these to see what they were doing.

In more or less all of the files in /etc/logrotate.d there is the postrotate command.

This fits in well with the output from /usr/sbin/logrotate -vf /etc/logrotate.conf.

The output states what is is doing based on the configuration files in /etc/logrotate.d and after each set of commands is processed, the following lines are to be found in the output:

Code:
running postrotate script
error: error running postrotate script
From what I can tell, whenever logrotate encounters the postrotate command, it outputs the above two lines.

Having had a look at the logrotate manual, I'm still no the wiser as to what "postrotate" actually is. I understand the purpose of "postrotate" when popped into logrotate.conf, or any subsequently included files, however I at a loss as to what is does and what script is actually executed.

So I've managed to figure out that logrotate generates an error when encountering "postrotate". From what I can also tell, no commands within logrotate.conf, or any other files that it includes, that occur after "postrotate" are executed.

Since "postrotate" is an internal command of logrotate, my thinking is that logrotate is a bit broken. Does this sound like a reasonable conclusion and, if so, how might I resolve it? Would reinstalling logrotate be an option and if so how?
 

webignition

Well-Known Member
Jan 22, 2005
1,876
1
166
The main indication that I think that there is something wrong with logrotate's postrotate command is that /etc/logrotate.d/apf and /etc/logrotate.d/bfd don't contain any scripts to execute after the postrotate command:

Code:
/var/log/apfados_log /var/log/apf_log {
    missingok
    postrotate
    endscript
}

/var/log/bfd_log {
    missingok
    postrotate
    endscript
}
The output from /usr/sbin/logrotate -vf /etc/logrotate.conf with regards to both of the above ends with:

Code:
running postrotate script
error: error running postrotate script
Since there are clearly no scripts executed after the postrotate command, it makes me think that logrotate is not working properly and may benefit from a reinstall.

Does this seem like a fair conclusion?
 

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,437
33
473
Go on, have a guess
Jon,

Are you running Fedora? If so, you might want to do the following (or try this anyway):

mkdir /mytmp

then edit pico -w /etc/cron.daily/logrotate and set the TMPDIR so it looks like this:

Code:
#!/bin/sh
TMPDIR=/mytmp
export TMPDIR
/usr/sbin/logrotate /etc/logrotate.conf
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
    /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit 0
Then run /etc/cron.daily/logrotate and see if it works.
 

webignition

Well-Known Member
Jan 22, 2005
1,876
1
166
Thanks for the suggestion Jonathan. And yes, FC2.

I tried what you suggested but I'm not sure if it either didn't work or if I did something incorrectly.

I modified /etc/cron.daily/logrotate as you suggested but I'm not sure how to run /etc/cron.daily/logrotate.

I just tried entering "/etc/cron.daily/logrotate" in an SSH window and pressing enter, but there was no output - nothing to say that it was in invalid command and nothing to say that anything had actually happened.

When running /usr/sbin/logrotate -vf /etc/logrotate.conf I'm still getting the same errors.

I'll post the full output of /usr/sbin/logrotate -vf /etc/logrotate.conf if you think it might help.

I'm not sure if its relevant, just straight after an email is received regarding the logrotate errors, two other emails arrive regarding the daily RulesDuJour update. I expect this is just due to the RulesDuJour cron task being after the logrotate task and somehow provoked by the logrotate errors.

Just in case this is relevant, the three emails arrive in the following order thusly:

Code:
/etc/cron.daily/logrotate:

error: error running postrotate script
error: error running postrotate script
error: error running postrotate script
error: error running postrotate script
error: error running postrotate script
error: error running shared postrotate script for /var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron
Code:
RulesDuJour Run Summary on core.webignition.net:

Ruleset for header abuse has changed on core.webignition.net.
Version line:
Code:
sh: -c: line 2: syntax error: unexpected end of file
The RulesDuJour daily update seems to work fine without a problem all throughout the rest of the week - its only when the logrotate errors are generated (due to the weekly rotation happening weekly) that the RulesDuJour update generates errors.
 

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,437
33
473
Go on, have a guess
Ah, it probably won't rotate until tomorrow. In the meatime you can do this for an interective test:

export TMPDIR=/mytmp
/usr/sbin/logrotate -vf /etc/logrotate.conf
 

webignition

Well-Known Member
Jan 22, 2005
1,876
1
166
Excellent! Thanks Jonathan, you saved my village.

Any chance you could voice a suggestion as to why the weekly logrotates might have worked before without a problem (or at least not that I noticed any problem)?

What might the side-effects be of "export TMPDIR=/mytmp"?

My (currently) limited understanding suggests that this is setting the environment variable TMPDIR. Is this at all related to /tmp? If I have any applications configured that have been told that the temporary directory is /tmp, would there be any problems? This may of course be completely irrelevant, but I'm just checking to be on the safe side.

Thanks again!
 

chirpy

Well-Known Member
Verifed Vendor
Jun 15, 2002
13,437
33
473
Go on, have a guess
It's a bug in Fedora Core when you have /tmp noexec which they've decided not to bother fixing - doesn't affect any other RedHat based Linux that I'm aware of:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=126259

Exporting like that will set the TMPDIR for that shell session only. When you log out, it's lost. So, you need to put it into that cron shell script as I mentioned earlier so that it is assigned whenever the logrotate CRON job runs.
 

adapter

Well-Known Member
PartnerNOC
Sep 17, 2003
391
0
166
i have the sampe problem on RHEL4.. just a info where i should create the mytmp direcotry? inside home?

what's happend if i dont fix this problem?

thank you
 

ncconquer

Well-Known Member
Jun 20, 2004
80
0
156
Same problem, i'm using WHM 10.6.0 cPanel 10.8.0-S59 - CentOS 4.2 i686 - WHM X v3.1.0
i was tried
mkdir /mytmp

pico -w /etc/cron.daily/logrotate

Code:

#!/bin/sh
TMPDIR=/mytmp
export TMPDIR
/usr/sbin/logrotate /etc/logrotate.conf
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
/usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit 0


and try:
logrotate /etc/logrotate.conf -f
--
error: error running postrotate script
error: error running postrotate script
error: error running shared postrotate script for /var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron


how to bug it?
 

lagoth

Member
Apr 5, 2003
24
0
151
Any ideas how to best resolve this on FreeBSD ? Install logrotate?

I notice cpanel don't install logrotate on BSD, it uses
/usr/local/cpanel/cpanellogd
to trim down 300 mb :eek: logs for
access_log
error_log
ssl_engine_log
suexec_log

but dont touch /var/log/exim/*

what would be the best way other then babysitting these logs on bsd? :)
 

ncconquer

Well-Known Member
Jun 20, 2004
80
0
156
this is report by command: /usr/sbin/logrotate -vf /etc/logrotate.conf
read attach file, please help to fix :(
---------
 

Attachments

consultorpc

Well-Known Member
PartnerNOC
Jun 18, 2003
51
0
156
Using lasted CentOS also don't work properly. According one cPanel techs it's the same problem and the fix is the same:

There is a small issue with logrotate where it will fail to rotate the logs
properly if you have /tmp securly mounted.

To correct this issue you would have to add something along these lines to the
top of /etc/cron.daily/logrotate


export TMPDIR=/root/tmp
if [ ! -e /root/tmp ]; then
mkdir /root/tmp
fi

this should correct that issue.

Regards,
 

Swaroop

Active Member
Jun 23, 2005
39
0
156
Jon,

Are you running Fedora? If so, you might want to do the following (or try this anyway):

mkdir /mytmp

then edit pico -w /etc/cron.daily/logrotate and set the TMPDIR so it looks like this:

Code:
#!/bin/sh
TMPDIR=/mytmp
export TMPDIR
/usr/sbin/logrotate /etc/logrotate.conf
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
    /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit 0
Then run /etc/cron.daily/logrotate and see if it works.
Unfortunately it seems to affect Centos 4.1 too... I had the same problem and your workaround fixed it.

Centos4, same problem, fixed all thanks to Chirpy! :D