Issue error_log continuously increases in size

[Joshua Ramirez]

Hey everyone. Today a client moved one of their WordPress sites over to my server and in doing so introduced a problem that caused /var/www/vhosts/domain_name_here.com/logs/error_log file to increase in size rapidly until it exhausted the entire hard drive space.

It was returning a known error reported by other KB articles and sites but no one seemed to post why this happens - why does the error_log file keep getting larger with the same message as if the WordPress site is stuck in a loop? It keeps posting "PHP Warning: is_dir(): open_basedir restriction in effect. File(/) is not within the allowed path(s)..."

I set open_basedir to none just to stop it from doing this but this isn't a safe method. Has any one else encountered this issue?

I imagine a error should be logged when this is triggered but only once or once everytime the site is accessed not until the log file grows to occupy the entire disk.

Thank you for your help

 

[Alberto Pizzarelli]

hello,

i think u must first of all control owner and permission of all files, your PHP run in fast CGI or modules?

 

[Joshua Ramirez]

Hi Alberto,

It's current running with FPM application served by Apache. What we ended up doing to resolve the issue is letting Plesk run permissions checks and fixes on the WordPress installation then disabling any caching plugins within WordPress. We were able to turn open_basedir {WEBSPACEROOT}{/}{:}{TMP}{/} (Default) back on after this.

Perhaps it was a permissions issue as you mention.

Why would the log file completely fill up until there's no more hard drive space?

 

[Alberto Pizzarelli]

confirm FPM whitout nginx?

 

[Joshua Ramirez]

Confirmed. I have nginx installed but for this particular instance or service plan, it's not running php with nginx. I'm running PHP 5.6.27.

 

[Alberto Pizzarelli]

if php run under apache but not suexec, the owner of files must be apache:apache, try set apache owner in tmp directory

 

[Bitpalast]

Identify the script and line where the is_dir() function is called that is mentioned in the error_log message. What is the target directory that is being checked for being a directory or not? This directory is outside your open_basedir path, therefor the system throws an error.

The reason for the error is that your client was on a different server with a different file and directory structure. His Wordpress installation still has references to the old paths stored in the database, so everytime a script is executed by Wordpress, this tests whether that path is a directory. The solution will be to identify the wrong path in the Wordpress tables, probably in wp_options, and to fix it there (adapt it to your server's path).

 

[UFHH01]

if php run under apache but not suexec, the owner of files must be apache:apache, try set apache owner in tmp directory

This is INCORRECT!

Files and folders INSIDE of "/var/www/vhosts/YOUR-DOMAIN.COM/httpdocs" should have the permissions: group: psacln / user: domain-system-user , while the domain document - root folder should have the permissions: group: psaserv / user: domain-system-user

Pls note: When you use PHP-FPM at your domain ( ... not matter what PHP - version you use! ) then ALL requests are handled with the domain - specific system - user and the group "psacln" ( you can verify that by having a look at your PHP-FPM - pool - definition for the corresponding domain!!! )
Depending to your operating system, you should have added the system - user "www-data" ( on Debian/Ubuntu - based systems ) / "apache" ( on CentOS/RHEL - based systems ) and the system - user "nginx" to the group "psacln":

usermod -a -G psacln www-data ( on Debian/Ubuntu - based systems )
or
usermod -a -G psacln apache ( on CentOS/RHEL - based systems )

usermod -a -G psacln nginx​

@Joshua Ramirez: Pls. consider to correct your permissions with the => Plesk repair utility <= using the command : plesk repair fs YOUR-DOMAIN.COM

 

[Joshua Ramirez]

Thank you everyone for the help and great information. I did notice as @Peter Debik stated and did make sure the permissions are set correctly as @Alberto Pizzarelli suggested.

I double checked permissions and they are set as other plesk domain accounts as @UFHH01 suggests.

I'm worried that future users will move their WordPress sites and the system will just crash again and I won't be able available to fix it (in a timely manner). To be clear on what happened, the user moved his WordPress site over and the log file continued to grow until the system ran out of disk space which of course shuts down pretty much everything.

We fixed it by doing the following;
1) Letting Plesk set WordPress permissions using their automated tool
2) Turning off any caching modules within WordPress
3) Double checking that no foreign directory structure calls existed

Then later, the user crashed it again but this time with an error of "PHP message: WordPress database error Got error 28..." . I read that this is because MySQL stated it was out of disk space. I suggested that the user turn off and leave off all caching WordPress plugins and the issue hasn't occurred again.

 

[UFHH01]

Hi Joshua Ramirez,

and the log file continued to grow until the system ran out of disk space which of course shuts down pretty much everything.

Did you ever consider to change your log - rotation behaviour?

Log Rotation ( Plesk 12.5 - online documentation - Advanced Administration Guide, Plesk for Linux )

If you limit the size and the amount of log - files, you will never reach any limits, which can result in your described issue. ​

 

[Joshua Ramirez]

Hey UFHH01,

Yes, I tried to change the way the Plesk reads and access the log file but only using the Plesk GUI at home -> service plans -> hosting plans -> logs and statistics. That didn't do anything though. I'll try what you suggest and let everyone know.

Keep in mind the log file grew extremely fast. I would watch it grow by the gigabytes in only a few seconds. I would have to replace the log file with an empty file to bring the server back to life.

 

[UFHH01]

Hi Joshua Ramirez,

consider to use an additional scheduled task ( could run every 5 minutes ) with a bash script, which might include file size checking ( using "du" ) and if a specific, maximum defined size is reached then move it somewhere else and create a new ( empty ) log - file.

Another suggestion is to run the log - rotation more often than once a day with the Daily Maintenance scheduled task, which can be as well done for a single domain, instead for all domains hosted on the server.

 

[Joshua Ramirez]

You guys rock. Thank you @Alberto Pizzarelli, @Peter Debik, and @UFHH01.

 

[Alberto Pizzarelli]

ciao @UFHH01

Files and folders INSIDE of "/var/www/vhosts/YOUR-DOMAIN.COM/httpdocs" should have the permissions: group: psacln / user: domain-system-user , while the domain document - root folder should have the permissions: group: psaserv / user: domain-system-user

I think your statement is incomplete.

depende the php if run under modules or cgi, if you run php whit apache mod_php, each file to be created or modified, will have as owner apache, and not the system user, this has also been reported as a major security issue, which eventually forced the use of fastgci whit suexec.

 

[Alberto Pizzarelli]

i'm sorry to all!!, but my english is a very basic level, i use a transaltor and same time, my post can be is incoprensible

 

[UFHH01]

I think your statement is incomplete.

No, it's not incomplete. The thread and the mentioned issue is based on the PHP-FPM - usage and the desired ( requested ) permissions on a Plesk - operated system. Again, pls. verify the answer with the help of the domain specific php-fpm - configuration, when you use PHP-FPM at your domain.