I have just had my server re-imaged from Plesk to Ensim Pro RHEL 4, the changeover went smoothly, (apart from Ev1 re-imaging with the wrong control panel, and had to do a 2nd re-image).

I only have two errors, one is with the cron and crontabs, but that I can live with. the other is the Logrotate! this is more serious.

When logrotate runs, it makes the old logs .1, .2, .3, .4 etc but the problem is that it is still updating to these logs and not the new empty one created.

So my APF AntiDos that use the /var/log/messages log to get data to work correctly just sees an empty log.

After trying to get this logroatation problem fixed with a trouble ticket, Ev1 have told me the following:-

There is a red hat bug that this version that you have " logrotate-3.7.1-5.RHEL4 " of logrotate was suppose to fix. But is still broken. Now the web page does say " Before applying this update, make sure that all previously-released errata relevant to your system have been applied. "
https://rhn.redhat.com/errata/RHBA-2005-333.html
Either way, we will have to wait for a the release of the next fix.
Regards,

Ev1


Does this mean that I have a server I cannot put any customers on.

Really Pissed Off.

Yeah, same thing happening to me.

If you HUP syslogd after the log rotate it'll work correctly.

/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null`

Oddly enough, that command is directly from the logrotate script. Why it's not firing I don't know. You can cron this yourself to run after logrotate.

Course that only fixes syslog. You can look in /etc/logrotate.d for everything that would need to restart.

I'm tempted to just disable logrotate.

I have got a crontab in root that restarts syslog after logrotate, but that has not solved the problem in this case, I think there is also a problem with the operation of crontabs, which Ev1 state on that ticket:-

Dear Customer,

For now we have reverted back your crontab configuration,but continue to look into your issue. We will update you once more information is available.

Regards,
EV1 Servers Support.

3/22/2006 10:19:37 AM
WebTech
Dear Customer;
There is a red hat bug that this version that you have " logrotate-3.7.1-5.RHEL4 " of logrotate was suppose to fix. But is still broken. Now the web page does say " Before applying this update, make sure that all previously-released errata relevant to your system have been applied. "
https://rhn.redhat.com/errata/RHBA-2005-333.html
Either way, we will have to wait for the release of the next fix.


Dear Customer;
I got rid of error: error running.
For apache logs, I changed
/bin/kill -HUP `cat /var/run/httpd.pid 2> /dev/null` 2> /dev/null || true
to
/bin/kill -USR1 `cat /var/run/httpd.pid 2> /dev/null` 2> /dev/null || true
This has worked in the pass. There may be a larger issue for the other logs.


I still don't think I can start putting customers on this server the way it is

The last message from Ev1 on this matter:-

3/22/2006 11:57:24 AM
WebTech
Dear Customer;
The logs are not growing rapidly. Only apache and a few other services are sensitive to log size and then they must be 2G to cause issues. When red hat releases a fix, up2date will install it for you. Until then check the log sizes.
Regards,


The logs are not growing because there are no customers at the moment!

(Please note where Ev1 talk about logs growing they are taking about the saved logs e.g. messages.1 and not messages ) and my antidos / APF will not work with an empty messages logfile, the Anti Dos checks this file for the last 150 lines every couple of minutes to protect against dos attacks.


Does anyone know of a fix to this problem?

I have altered my cron.daily file 'z_syslog_restart' and put the line in that you suggested, I hope this will work.

This issue with logrotate seems to be a long standing problem with RHEL and not just on the latest version.

I have just run that line from the command line, and it seems to be working, I just hope the crontab works! tomorrow at the next logrotate.

Thanks for your help.

Thank's Smack,

Your line that I copied in my crontab worked!

The logs rotated correctly this morning and all the logs are now updating where they should.

Great Fix... (So Simple As Well)

any news from redhat on this issue?

I noticed this problem earlier today on a RHEL4 box that ev1 imaged for me last week. My Apache logs existed but were empty and the .1 log was still growing. I haven't checked yet but I presume the same is true of the other entries in /etc/logrotate.d/.

Is anyone at RedHat actually working on this bug? The activity log on the bug quoted earlier in the thread seems to indicate it's been forgotten.

I ran /usr/sbin/logrotate -v -f /etc/logrotate.conf and it produced a couple of odd entries like this one for httpd:

running shared postrotate script
error: error running shared postrotate script for /var/log/httpd/*log

and this one for the syslog:

running shared 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


Notes:

My /etc/logrotate.d/httpd file and /etc/logrotate.d/syslog are essentially stock:

/var/log/httpd/*log {
daily
rotate 7
missingok
notifempty
sharedscripts
postrotate
/bin/kill -HUP `cat /var/run/httpd.pid 2>/dev/null` 2> /dev/null || true
endscript
}

/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron {
sharedscripts
postrotate
/bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
endscript
}

Yes it's very strange that they haven't updated this bug report at redhat for so long... this is imho a serious problem that's affecting every RH4 user. :confused:

Also surprising that there's so little feedback to redhat to fix this issue... is everyone doing the custom fix by themselves?

Here's the fix for at least half of you ...

/etc/cron.daily/logrotate:And you you get funky "kill [options]" lines, and you're on Ensim, then change /etc/logrotate.d/mysqld to the correct pid path (/var/run/mysqld_app_init/mysqld.pid) and put a "#" in front of the "kill" line in /etc/logrotate.d/clamav (unless you have clamd turned on and need it).

This is essentially the fix I'm in the process of investigating. Apparently our logrotate problems are due to the fact that /tmp is being mounted noexec under RHEL4.

Redefining TMPDIR is *supposed* to fix this problem and allow the -HUP in the various prerotate/postrotate routines.

I'm still annoyed RedHat didn't provide a fix in RHEL4 update 3.

Works perfectly for me. If /tmp is mounted noexec in your /etc/fstab, this export TMPDIR technique should work fine for you.

I guess the only thing to keep in mind is that an updated logrotate RPM will replace /etc/cron.daily/logrotate.

I've tried the two solutions posted before and no one solved the issue, are there any news about it?

Thanks

I can't believe there's still no fix for it by redhat.... seems they don't listen to small guys like us... someone from EV1 should tell them to get it fixed.

So who created the Bugzilla report then?

I have installed the same Ensim software on the same RHEL4 and have the following logrotate problem. Periodic logrotate works fine, but size limit logrotate doesn't. Although i e.g. set maximum log file size to 350k it can fill up all my disc space. Anyone can help?

Thanks,
Mario

350k?

Wow - sheesh. mine are 335MB

FYI, the above fix worked for my RHEL4/EnsimX server but it did require a reboot to kick things into gear. At least after upgrading the kernel and rebooting the server to the new kernel it is working

Is it safe to upgrade the kernel via up2date? Any exclusions, any specila considerations? or can you provide soemd etail on what you did and how you did it?

I am looking to upgrade to Ensim X to, but I want to be sure everything goes fine.

THanks.

I have made the changes as specified above to fix this issue, and I am still getting the postrotate errors and logs not rotating. Restarting syslog appears to get them going again, but does anyone know how to make this a permanant fix so a syslog restart isn't required?

The update is available since October 2006, but it hasn't been added in rhn.ev1servers repository. When will it be available?

The problem is more serious than it might seem; users that do not double check, won't realize that their logs aren't being rotated properly; this means that software popular among ev1servers, like antidos, will be useless, because it will be parsing an empty /var/log/messages files, since logs could be saved in rotated files like /var/log/messages.2 instead than the main file.

So is it available in the rhn repositories? I put in a ticket with Ev1 enquiring about it and this is the response I received:

"Our up2date repository is current. At the moment we are waiting for RHN to release these packages to us. Once we have them you will be able to use them. I apologize for the inconvenience this may have caused. Thank you."

Yep, they are already available on RHN; please check:

http://rhn.redhat.com/errata/RHBA-2006-0696.html

I got the exact same reply. Apparently, it is RedHat's fault for not having sent the updates to ev1servers yet. Right now, the only solution you have is creating a different tmp directory for logrotates only. And if you do not like the idea of having yet another tmp directory on your system which allows execution of files, you can create it at the beginning of /etc/cron.daily/logrotate and delete it at the end of the script.

And let me stress again the fact that this is a relatively important issue - if logs aren't rotated properly, a lot of security scripts won't work properly or at all. For example, if your syslog logrotation - which in RHEL 4 is done with logrotate instead than with the usual syslogd internal log rotation - is broken, rfxn's antidos could not work, because /var/log/messages is empty.

You can also compile the source RPMs by yourself;

1 - as root, download the SRPM from RHN:
wget http://ftp.redhat.com/pub/redhat/linux/upd...6.RHEL4.src.rpm
2 - build the rpm
rpmbuild --rebuild logrotate-3.7.1-6.RHEL4.src.rpm

This should do it; rpm -q logrotate should now list the package logrotate-3.7.1-6.RHEL4

Easy solution:

Add to /etc/cron.daily/logrotate

export TMPDIR=/var/run

Yes, that is what I meant when I said to create and delete another directory. But if on your system you have to set 777 permissions on the directory, you have another directory where everybody on the server can write and execute anything.

Installing the rpm is easy, and should fix everything on most RHEL 4 based systems.

I can appreciate that ev1servers is stating that their RHN repository is up to date, however this is a fairly critical (albeit easy to fix manually) issue. Doesn't EV1 have support (or several?) contracts in place with Redhat? In my eyes, EV1 is one of the few providers who pushes the commercial Redhats even.

With those things said, I find it difficult to see why EV1 is having difficulty getting an up to date repository when this patch was made available over 2 months ago. :confused:

Would the CENTOS version of the rpm be the exact same?

http://mirror.centos.org/centos/4/fasttrack/i386/RPMS/

logrotate-3.7.1-6.RHEL4.i386.rpm

I'm showing logrotate-3.7.1-5.RHEL4.i386.rpm when I grep the rpm currently being used on my server.

CentOS3 = RHEL3. CentOS4 = RHEL4.

That's what I was getting at. If up2date isn't updating it for me (which is run every night), I should just use the readily available "free" OS version. It seems better supported anyway.