logrotate ... uses excess cpu ?

we are getting a huge server load every day and we found it to be logrotate that stops server

in logs we find

  Mar 28 06:58:56 u15331601 statistics: Unable to get current data: Table 'psa.SitePagesStat' doesn't exist
Mar 28 06:58:56 u15331601 statistics: Unable to clear data: Table 'psa.SitePagesStat' doesn't exist
Mar 28 06:59:05 u15331601 statistics: Unable to get current data: Table 'psa.MailMessagesStat' doesn't exist
Mar 28 06:59:05 u15331601 statistics: Unable to clear data: Table 'psa.MailMessagesStat' doesn't exist




problem  is we do not have these tables

can we create empty tables to solve problem  or??
webguy62Asked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
Duncan RoeConnect With a Mentor Software DeveloperCommented:
In view of the number of messages you are getting, I would change /var/log/messages to -/var/log/messages (with minus sign as you already have for mail).
logrotate looping is highly unusual. If your guy had to delete some large files, it would seem that logrotate wasn't working anyway, or perhaps wasn't well configured.
To find out what logrotate is doing, first determine its process ID (pid). If the loop it is in includes a system call, strace will show something: strace -f -p pid.
Failing that, you are probably looking at building logrotate from source with debug symbols and attaching to the process with gdb. But lsof (list open files) may give you a clue: lsof -p pid.
Just possibly, logrotate has encountered some kind of file system corruption which has led it astray. Before going the gdb route, you might like to try a forced fsck (file system check) of the partition containing the log files. I'm assuming for now you know how to do that (single-user, remount root (/) read-only, ...)
0
 
johanntagleCommented:
I doubt if the missing tables are the ones causing high load.  How did you determine it was logrotate consuming the cpu?  Did you use a utility like top?
0
 
Duncan RoeSoftware DeveloperCommented:
You have an application that is logging these messages. That will severely impact the system, unless you put a minus ("-") sign in front of that log file name in /etc/syslog.conf . The effect of not having a minus sign is that the entire file system is sync'd every time a message is logged (i.e. all written buffers are flushed to disc before proceeding).
In the long run, you want to find what application is logging the messages. You may decide it is not of sufficient value to be running at all. Otherwise, its documentation should point you to the real meaning of the messages, and what you have to do to stop them being logged.
0
Never miss a deadline with monday.com

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

 
webguy62Author Commented:
yes we ran top and saw it was logrotate

now we have to killall - 9 logrotate

how do we find what causes the logrotate to use all cpu?
0
 
webguy62Author Commented:
the below is syslog.conf    do we need to change this? I was told one of our guys manually deleted some logs in a few domains that were real large. could this cause it? and if so how to fix

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                          /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none            /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                    /var/log/secure

# Log all the mail messages in one place.
mail.*                                    -/usr/local/psa/var/log/maillog


# Log cron stuff
cron.*                                          /var/log/cron

# Everybody gets emergency messages
*.emerg                                          *

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                    /var/log/spooler

# Save boot messages also to boot.log
local7.*                                    /var/log/boot.log
0
 
webguy62Author Commented:
this solved the problem it took few days to monitor the server to verify but all is well now :)
0
All Courses

From novice to tech pro — start learning today.