Big phpXXXXXX files in /home/USER/.cagefs/tmp

  • Hi all.

    I have some users with huge tmp files (between 500MB and 2GB) in /home/$USER/.cagefs/tmp/phpXXXXXX. I noticed that if I configure high values for “max_execution_time” and “lsapi_backend_max_process_time” this tmp files appears to grow infinitely.

    Example of temp files (with “lsapi_backend_max_process_time = 300”):

    [root@server ~]# ls -larth /home/$USER/.cagefs/tmp/php*
    -rw——- 1 $USER $USER 700M ago 24 10:47 /home/$USER/.cagefs/tmp/php3bLX6P
    -rw——- 1 $USER $USER 752M ago 24 10:48 /home/$USER/.cagefs/tmp/phpyQVlXK
    -rw——- 1 $USER $USER 1,2G ago 29 05:00 /home/$USER/.cagefs/tmp/phpTVL8ud
    -rw——- 1 $USER $USER 1,2G ago 29 19:04 /home/$USER/.cagefs/tmp/phpEWRNjt
    -rw——- 1 $USER $USER 1,2G ago 29 21:16 /home/$USER/.cagefs/tmp/php5IRtuJ
    -rw——- 1 $USER $USER 1,1G ago 30 05:47 /home/$USER/.cagefs/tmp/phppCg2ag
    -rw——- 1 $USER $USER 1,2G ago 30 15:31 /home/$USER/.cagefs/tmp/phpFvflBt
    -rw——- 1 $USER $USER 1,2G ago 30 18:55 /home/$USER/.cagefs/tmp/phpl438Jl
    -rw——- 1 $USER $USER 1,2G sep 1 04:40 /home/$USER/.cagefs/tmp/phpnvjn9N
    -rw——- 1 $USER $USER 1,2G sep 1 05:06 /home/$USER/.cagefs/tmp/php5afzuV
    -rw——- 1 $USER $USER 1,2G sep 1 11:52 /home/$USER/.cagefs/tmp/phpO427u7
    -rw——- 1 $USER $USER 1,2G sep 1 14:39 /home/$USER/.cagefs/tmp/phpbRucIl
    -rw——- 1 $USER $USER 1,2G sep 3 05:57 /home/$USER/.cagefs/tmp/phpie8a2k
    -rw——- 1 $USER $USER 656M sep 3 16:23 /home/$USER/.cagefs/tmp/phpHNSknY
    -rw——- 1 $USER $USER 818M sep 3 16:24 /home/$USER/.cagefs/tmp/php5H7kSj
    -rw——- 1 $USER $USER 1,2G sep 3 17:41 /home/$USER/.cagefs/tmp/phpJiCASm

    I verified that if I disable wordfence this tmp files are not created.

    System info:

    Wordfence 6.3.18
    Wordpress 4.8.1
    CPanel 11.66.0.17
    CloudLinux release 7.4 (Georgy Grechko)

    I see this problem in several users in different servers (All with the same config as above).

    Any ideas?

    Regards.

Viewing 12 replies - 46 through 57 (of 57 total)

  • Goodmorning @wfmattr!

    Thanks for your reply!

    That is a temporary fix that I can not make ??
    The website is now on some server especially for WordPress – extra fast.
    I can not change that to another way to run the PHP ??

    Plugin Author WFMattR

    (@wfmattr)

    @anna-webdesign: Ok. Can you double-check that the site isn’t using “Extended Protection” on the Firewall page? The WFWAF_DISABLE_RAW_BODY is definitely preventing the issue on another site we’re using — if extended protection is on, it needs to be defined in wordfence-waf.php instead of wp-config.php. If it’s not, that might be related to the WooCommerce connection you mentioned before. (Even if ours is disabled, perhaps theirs still runs during certain requests?)

    Either way though, the dev team will be making a workaround for this after our upcoming release, to prevent the large temp files from being created when a bad request is being processed. (For anyone catching up on this thread — the POST body in these requests is actually missing, due to a broken pipe while PHP tries to read the body.)

    -Matt R

    @wfmattr Thank you for the reply. The webshops where it happend are way to busy to test these kind of things. I replaced the plugin with another plugin for now.

    Thanks for you help!

    Hello here,

    I have the same problem. Large temp files (around 1 gigabyte each) keep being created in my folder /home/myusername/.cafegs/tmp… everytime I have to manually delete them

    Digging around this particular thread, I decided to change the max_execution_time from 180 to 60, someone suggested it could do the trick. But this is still hapeening.

    I also went premium on Wordfence, hoping it would solve the case… and obviously Wordfence is up to date to the last version…

    Any way you could help me? Since I’m on a premium key, should I go through the Premium support in my Wordfence dashboard?

    Nicolas.

    Plugin Author WFMattR

    (@wfmattr)

    Hi all,

    @nicolasdaudin: I saw that you had entered a premium support case and got a reply already, so you can continue replying there if you still have any trouble.

    For anyone else still having this issue, the temporary solution using WFWAF_DISABLE_RAW_BODY mentioned above should work — if you still have trouble after adding it, make sure it is in the right place, depending on whether your Wordfence firewall says “Basic WordPress Protection” or “Extended Protection” (detailed previously).

    We’ve tried a few workarounds as I mentioned we would do, above, but ran into other PHP issues — either excess memory usage, or inconsistencies reading from streams.

    I’ve found a way to reproduce the effect in PHP without WordPress or Wordfence and submitted a PHP bug (https://bugs.php.net/bug.php?id=76058) a couple weeks ago, but the PHP dev team has not worked on it yet. I’m not sure what their usual turnaround time is. The bug is normally only triggered on CloudLinux servers, as far as I can tell, but it is intermittent and happens more on busy sites — so it might be harder for the PHP team to work on than typical bugs.

    For anyone who is a CloudLinux customer, I’ve sent them the same details, but it would help them sort it out if they had access to a server that currently has this issue — you can try emailing them at [email protected], and mention that the issue is related to request #27132.

    If you don’t run a server yourself, but use a hosting company that is a CloudLinux customer, you can also ask your host to contact CloudLinux the same way.

    We’ll still look at possible workarounds, if there is anything we can do without affecting the vast majority of sites that aren’t having an issue — but the underlying issue needs to be solved in either PHP or CloudLinux’s mod_lsapi.

    -Matt R

    I just mailed CloudLinux with access to a server. I referenced #27132.

    CloudLinux has told me:

    Hello,

    It appears that the issue should be fixed in the upcoming alt-php group release, where LiteSpeed SAPI will be updated to the version 7.0

    The task ID is ALTPHP-464 (for your reference), we will mention it in our blog.

    After it is available I will test it as soon as I can and post the results here.

    Can I delete those phpXXXX files? Is it safe?

    I did it and had no problems. So i guess – do it! ??

    Any idea if this was fixed with the PHP 7.2 release? Experiencing it now with 7.1 on GoDaddy Linux server.

    I didn’t have that problem after upgrading to 7.2, apache.

    Plugin Author WFMattR

    (@wfmattr)

    @three16design: CloudLinux confirmed fixing the issue in lsphp, but didn’t mention if it was only done in some PHP versions — I expect that it should be fixed in all PHP versions that they currently support. (The underlying issue in PHP itself still has not been addressed: https://bugs.php.net/bug.php?id=76058 )

    If you need it, we added a checkbox on the Tools menu, on the Diagnostics tab, near the bottom in the “Debugging Options” section Disable reading of php://input — checking that option prevents Wordfence from using php://input, which is where the PHP bug occurs.

    (Alternately, you could use the WFWAF_DISABLE_RAW_BODY constant described above to disable this, but it’s a bit more involved.)

    If you still have large temp files showing up, you might have another plugin that uses php://input, which could trigger the same bug.

    -Matt R

Viewing 12 replies - 46 through 57 (of 57 total)
  • The topic ‘Big phpXXXXXX files in /home/USER/.cagefs/tmp’ is closed to new replies.