• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Log Rotation Broke

A

alpheus

Guest
I have a domain set to do a log rotation of 50000 KB, but yet it does nothing. The error_log on this domain (which is access by going to /var/www/vhosts/thisdomain.com/statistics/logs/" and then doing "ls -la" on the directory) is reaching about 2gb in file size in about an hour getting filled with php warnings. Plesk is suppose to be rotating this log once it hits 50mb. Any idea why Plesk is not preventing this log from reaching above 50mb and in fact the log file is reaching several gigabytes very rapidly w/o being rotated? Thanks!
 
Try to run manually following command from cron task /etc/cron.daily/50plesk-daily:

# /usr/local/psa/bin/sw-engine-pleskrun /usr/local/psa/admin/plib/DailyMaintainance/script.php

and check output and that log file was rotated.
 
Thank you for the reply. Forgive me, but I'm some what new to Plesk. Should the command be: "/etc/cron.daily/50plesk-daily:" on my scheduled task? Should I include the ":"?

This looks like something I would do in console "# /usr/local/psa/bin/sw-engine-pleskrun /usr/local/psa/admin/plib/DailyMaintainance/script.php". When(after I setup the cron task?) and where(console?) do I run this?

Thanks!
 
Just try to run

# /usr/local/psa/bin/sw-engine-pleskrun /usr/local/psa/admin/plib/DailyMaintainance/script.php

command in CLI and check output for possible errors and that log file was rotated.
 
I ran /etc/cron.daily/50plesk-daily from console and it seemed to rotate the log correctly. However it also increased my resources quite a bit as cpu went above 100% and load above 1.0. With that being said, I'm going to want to run this script about every 30 mins (but don't want the massive cpu increase). Is there a less CPU intensive way to run a log rotate on one domain specifically? One that can be setup through the domain's plesk panel via scheduled tasks?
 
You shouldn't do something with this cron script. It should work correctly by default and it does not require any corrections/modifications from user's side.
 
That's the problem, I think this is only running once per day, and this domain's error_log is accumulating to 15gb + before the script is even ran on that once per day.

I'm trying to setup a cron that can be ran every 2 hours to rotate logs on that domain specifically that is not cpu intensive. The command you provided would run a cpu intensive task and would reflect all domains on the server, not just that specific domain. Unless I am mis-understanding something.
 
Maybe the best way for resolving this issue is elimination of reasons of fast log size growing?
 
That's not an option at the moment. It's creating due to massive php warnings on a site that is heavily visited. They are revamping their entire site so those will go away, however it's not in the scope to replace those now. So there is not any kind of cron I can setup in the plesk domain panel to rotate the logs? Or another script I can run other than /usr/local/psa/bin/sw-engine-pleskrun /usr/local/psa/admin/plib/DailyMaintainance/script.php >/dev/null 2>&1 (cpu intensive)?
 
I think that in any case gzipping of huge log file will take a lot of CPU resources.
 
Makes sense.

So does /etc/cron.daily/50plesk-daily only rotate logs, or does it try to perform other tasks as well that could also be using cpu usage?
 
Yes, it is multifunctional script for usage in different purposes. Statistics calculation, for example.
 
Ok, I think I have enough to work with. I disabled awstats, changed number of logs to create from 10 to 3, and removed compression. As a result, the script run much faster and less cpu intensive. I have set up the cron at root user level instead of at the users domain level to run once an hour. I think that will do it for now.

The cons is that the user on the server can no longer utilize aswstats and won't have as many log files to choose from, nor will they be compressed. I'm assuming I'm doing this the most efficient way. If you can think of another way, I'm open ears as well.

Thanks for all your help and your quick responses!
 
Back
Top