• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Issue error_log not rotated properly since approximately February update

Bitpalast

Bitpalast

Plesk addicted!
Plesk Guru
I think there could be a bug since one of the recent upgrades that during the "ExecuteStatistics" tasks of "# plesk daily" the error_log files of the domains are no longer rotated.

When I run logrotate directly with the Plesk-generated configuration file, e.g.
# logrotate -f /usr/local/psa/etc/logrotate.d/<domain name>
all works well. Log files including error_log file are rotated.

But during the nighly maintenance this is not happening anymore. I still see a migration from e.g. access_log to access_log.processed, but it seems that the full rotation scheme is no longer executed. I have already tried solutions like
and similar, but still end up with large error_logs, e.g. >2 GB, in some domains that have clearly set the max log size to 10 MB. While - again - the file is properly rotated when running "logrotate" stand-alone with the Plesk-generated configuration file for log rotation.

Is this an expected behavior? Does anyone else see a similar behavior on their servers?
 
Last edited:
Peter, the developer informed me that nothing was modified in logrotation components in the latest Plesk updates.
 
I can confirm this is the case, I just noticed this today as well while working on a MediaWiki Update, the error_log wasn't rotated since early march and has gotten to a sizeable 6 GB. The same was true for access_logs, which is at 1.2 GB. And php-fpm_error.log as well.

Manual logrotate worked here as well. We hadn't made any changes to logrotate and just have the plesk autoupdates running, so it's likely there is a plesk problem if Peter also noticed that.

Other logs rotate normally.

@Peter Debik If you happen to find a solution I'd be very happy if you shared it :)
 
Here is a screen, actually only the access_log was rotated when doing the fix mentioned by Peter. The error_log doesn't rotate on manual either.
 

Attachments

  • logs.png
    logs.png
    24.2 KB · Views: 11
That matches pretty much what I see on the servers here. Even the dates in your screenshot that with early March the daily rotation scheme for error_log stopped. Very similar, so very likely the same issue. Thank you for sharing.
 
I just tried the "logrotate -f /usr/local/psa/etc/logrotate.d/<domain name>" way you had mentioned in your post, the error_log was removed, but not rotated. It's just been emptied. Weird. Maybe that was a problem due to it having become so big, but I see that my access_log also has not been put into an archive, but was emptied as well. I will watch if normal rotation happens starting this night. It's only a few hours towards it.

I hope I didn't loose my web-stats for today due to this :(

//EDIT: Yes, every manual execution of the logrotate command just empties the log, nothing else.
 

Attachments

  • log.png
    log.png
    45.7 KB · Views: 4
So, I have no idea what I'm actually doing, but executing
/usr/local/psa/admin/sbin/statistics –calculate-one –domain-name=<mydomain> does correctly rotate the logs?

You can now see the previously vanished big logs that were rotated into packaged files (100 MB and 75 MB). How is that even possible, when they were gone prior, as you can see in my last screenshot?
 

Attachments

  • logs.png
    logs.png
    30.6 KB · Views: 4
The size can't be the problem. I've done the same today on a log that was 150 GB. The process ran for a long while but it completed successfully.
 
Interesting. So I can reproduce the following on my instance:

logrotate command does visibly only empty the file, nothing else. Only when I execute /usr/local/psa/admin/sbin/statistics –calculate-one –domain-name=<mydomain> the rotation actually happens.

So If i execute logrotate three times, I will have nothing but an empty log file, but when I then execute /usr/local/psa/admin/sbin/statistics –calculate-one –domain-name=<mydomain> I will have three new rotated files, just as many as times i have executed logrotate.

Very weird behaviour. Well, I let you experts deal with this and I just monitor if stuff works better this automatic rotation.
 
D3nnis3n said:
So, I have no idea what I'm actually doing, but executing
/usr/local/psa/admin/sbin/statistics –calculate-one –domain-name=<mydomain> does correctly rotate the logs?
Click to expand...
It did not do it here. It should, but it did not do the full rotation. Only logrotate did.
D3nnis3n said:
You can now see the previously vanished big logs that were rotated into packaged files (100 MB and 75 MB). How is that even possible, when they were gone prior, as you can see in my last screenshot?
Click to expand...
That is possible. Rotation is a multi-step process. First a copy of the original log file is created, then the original is replaced by an empty new file, then the existing compressed files are renamed and finally the log file copy is gzipped. It is thinkable that there is a short latency between steps.
 
That latency being at least 15+ minutes, while executing stats doing it correctly immediately seems odd to me.

In any case, it feels like something here is no longer working correctly since early march. None of what I saw today has been an issue before.
 
No problem, much better to know there is an issue than wondering what is going on, thank you so much.

By the way:
Does anyone know for chance how I can correctly remove / rotate php-fpm_error.log? I have deleted the log about six times now, but after a few hours it's just back again with all the contents it had pre-removal. It has 60 GB by now and needs to go, my disk is getting full. (They get spammed by deprecation warnings from a MediaWiki extension, we unfortunately need to use)
 
@D3nnis3n I was able to reconstruct your symptom that after a "logrotate" the rotated files seem to be not visible. Here it is indeed the /var/www/vhosts/<subscription>/logs version of these files that are not immediately visible. However the "live" and original file version in /var/www/vhosts/system/<domain>/logs is immediately updated. Approximately 15 minutes later the /var/www/vhosts/<subscription>/logs is also updated.
 
Interesting. My logs have indeed rotated for the first time since the bug, on all my servers.
Haven't done anything else than install the update yesterday and checked up on it today.
 
You must log in or register to reply here.

Similar threads

M
Issue Rotation of files with multiple hard links is not allowed
Replies
3
Views
1K
Bitpalast
Bitpalast
burnley
Issue [17.5.3] Plesk for Linux logrotate issue: error_log not rotated
Replies
1
Views
1K
burnley
burnley
K
Logrotate for error_log does not work for migrated domains
Replies
2
Views
1K
Kurt Ludikovsky
K
Bitpalast
Resolved Intra-day log rotation: Is there an easy way to set it up?
Replies
1
Views
954
Lloyd_mcse
Lloyd_mcse
Bitpalast
Forwarded to devs Let's Encrypt still causing issues with web server configuration on updating certificates
Replies
11
Views
2K
Bitpalast
Bitpalast
Back
Top