Solved

logrotate ... uses excess cpu    ?

Posted on 2012-03-28
6
607 Views
Last Modified: 2012-04-06
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??
0
Comment
Question by:webguy62
  • 3
  • 2
6 Comments
 
LVL 24

Expert Comment

by:johanntagle
ID: 37780162
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
 
LVL 34

Expert Comment

by:Duncan Roe
ID: 37781062
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
 

Author Comment

by:webguy62
ID: 37781865
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
Ransomware-A Revenue Bonanza for Service Providers

Ransomware – malware that gets on your customers’ computers, encrypts their data, and extorts a hefty ransom for the decryption keys – is a surging new threat.  The purpose of this eBook is to educate the reader about ransomware attacks.

 

Author Comment

by:webguy62
ID: 37781904
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
 
LVL 34

Accepted Solution

by:
Duncan Roe earned 500 total points
ID: 37784346
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
 

Author Closing Comment

by:webguy62
ID: 37816539
this solved the problem it took few days to monitor the server to verify but all is well now :)
0

Featured Post

Master Your Team's Linux and Cloud Stack!

The average business loses $13.5M per year to ineffective training (per 1,000 employees). Keep ahead of the competition and combine in-person quality with online cost and flexibility by training with Linux Academy.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

If you've heard about htaccess and it sounds like it does what you want, but you're not sure how it works... well, you're in the right place. Read on. Some Basics #1. It's a file and its filename is .htaccess (yes, with a dot in the front). #…
Join Greg Farro and Ethan Banks from Packet Pushers (http://packetpushers.net/podcast/podcasts/pq-show-93-smart-network-monitoring-paessler-sponsored/) and Greg Ross from Paessler (https://www.paessler.com/prtg) for a discussion about smart network …
Learn several ways to interact with files and get file information from the bash shell. ls lists the contents of a directory: Using the -a flag displays hidden files: Using the -l flag formats the output in a long list: The file command gives us mor…
This demo shows you how to set up the containerized NetScaler CPX with NetScaler Management and Analytics System in a non-routable Mesos/Marathon environment for use with Micro-Services applications.

776 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question