Jump to content

How to get rid of logrotate and gzip every night?


Recommended Posts

On my server there is  thing called logrotate that starts around 4am, its hogs all the cpu and the server becomes unresponsive.

The thing is I have no logs on my apache, I have disabled it, so what is it gzipping every night? I have no idea.

 

 

How can I track this down and figure out what it is? I would like logrotate to just delete the logs whatever the heck they are I dont really care what they are, they can't be important can they. :shrug:

 

So where I do start? is there like configuration file for logratate that says what it is rotating?

how did you come to the conclusion that it was logrotate that was causing the problem? if it was via `top`, then paste the entire line with the parameters of the logrotate command.

 

also, i think it's much safer to spend a few minutes figuring out what log is being rotated before you decide to do away with it.

tell me what distribution you're running.

 

 

if you really want to disable logrotate, you can prepend all the lines of /etc/cron.daily/logrotate with a '#' in order to comment it out.

 

 

however, i still think you should figure out which log is being rotated and then come to a decision.

the way to do that is, as i said, show me the output of `top` that shows logrotate running. if you figured out logrotate was the culprit some other way, then let me know how.

 

OR

 

post the contents of /etc/logrotate.conf

Yes I'm pretty sure it Logrotate, I've noticed on many occasions while up at night  logrotate come appear in TOP, then after that Gzip.

Its Gzip that hogs all the cpu, the thing is, its around 1 hour for it to gzip all the logs.

 

Now since I have Squid Cache in front of my Apache, So I disabled apache logs, since everyone will appear from 127.0.0.1, its not much use anyways.

 

I found this.

 

/etc/logrotate.d/  which it appear its rotating mysql, sshd logs, squid etc.. Which I didn't think about would be making logs.

So how I can tell logrotate to just delete say the mysql logs instead of gziping them?

the files in /etc/logrotate.d are just the configuration files.

these config files tell logrotate where the actual logs exist and how often you want them rotated and other things.

 

by default, most linux's would store your logs in /var/logs

 

i don't recommend you actually disabling your logs unless you're absolutely sure you'd need them.

what you can do, however, is to remove the files in /etc/logrotate.d

the files that you remove will not go through logrotate.

 

also, post your crontab listings.

this should post the crontab of the user you log in as:

crontab -l

 

in case you don't log in as root, this should display the root users crontab:

sudo crontab -u root -l

What size are your log files in /var/log?

 

Logrotate also starts and stops services when it rotates logs, so you might want to look into that.

Logrotate, afaik, rotates apache logs only once a week.

 

You need to look in: /etc/logrotate.conf and /etc/logrotate.d/* and look at the config files.

 

The cron job which runs logrotate is stored in:

/etc/cron.daily/logrotate

Ive rarely seen logrotate to hang a system. Its much more likely that there are other tasks running from /etc/cron.daily/*

What you could do is: In /etc/cron.daily/ remove logrotate for a day to see if it makes a difference.

 

-steve

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.