Plugin writing tons of files to /tmp/ folder

Just to add a clarification, I checked another one of my servers and it does seem like it has some of these files as well. However it hasn’t grown nearly as large in number to where it’s slowing down responsiveness to the site.

There’s no reason why the plugin itself would be trying to write to /tmp/

My feeling looking at this is that automatic background updates has been repeatedly trying to write out these temporary files to disk, and failed. Since when a plugin update happens, it downloads the update package to a temp location, extracts it, deletes the contents of the current plugin and then moves in the new files.

This is the only way I can explain why you’d have these tmp files there. CAn you delete these tmp files, ensure the plugin is up-to-date and then regularly check back that these files aren’t being written any longer.

Then, perhaps when the next update is released, you could not manually update the plugin and see if these tmp files appear…?

That’s my first suggestion, but thanks for raising it with me- I’ll ponder it to see if anything else could be going on.
Paul.

Hi Paul,
Thanks for the reply. I could see that perhaps being the case, but it’s perplexing to me that only the WordPress Firewall would be writing such files to /tmp/. I have about 30+ other Plugins installed, and none of them post these files. Also, these files are showing up even though I’m already on the latest version of the plugin. I just checked this morning and there are new files in there, even though I’m on the latest version.
Let me know if you have any other thoughts!
-Mark

Hmmm… very odd. The reason other plugins wouldn’t be showing the auto update behaviour is probably because they wouldn’t be coded to use the WordPress background updates system. The WPSF is.

Do you have any errors in the error log? My guess would be something could be showing in there if a process was started and interrupted for whatever reason..

Is it all just files beginning with “feature-” ?

I’ve looked in the WordPress source and I’ve found the function that does this: wp_tempnam().

It creates files of this pattern and it’s called by “downloard_url()” which is called when any plugin updates so it can get the update package. Can you try turning off the auto updates option for the plugin itself (under the auto updates feature section).

Thanks!
Paul.

Hi Paul,
Not all the files begin with “feature” here are a few others that are different:
plugin-spec135.tmp
That seems to be the only variance, the rest are feature.

I can confirm that turning off the auto updates option for the plugin itself does seem to stop those files from populating! That seems to do the trick. Maybe I’ll just leave that off permanently.

FWIW, the server that was populating with tons of files wasn’t allowing updates of plugins through the WordPress Admin, something was configured wrong in the Linux permissions, so it couldn’t update plugins. We were having to manually upload them. So, perhaps it’s somehow connected that it’s downloading the updates to /tmp/ but doesn’t have permissions to do anything with them, so it just keeps filling up?

Yes, that makes sense… if you effectively don’t have write-to-disk permissions WP will just continue to write these files and fail, creating lots of 0 byte files. Now why, even though the plugin was up-to-date, WP was trying to auto-update WPSF, I don’t know. Sounds like there was some stale update information being store and WordPress “thought” there was an update, when there wasn’t.

If you’ve fixed your WP disk write permissions, I’d turn back on Auto updates for WPSF and allow it to complete the update it thinks it needs – WP will just report back that now update is necessary if it tries it, and will then clear out any update info for the plugin and you’ll be back to normal.

Keep me posted! Ideally you’ll want auto updates for WPSF. ??

Cheers!
Paul.

Hey Paul,
One more question comes to mind related to this issue. I’m curious why this mass of files would slow down publicly loading the website? Is that a function of the Firewall, or more of a general feature of WordPress itself? It’s concerning to me that a failure of automatic updates, which creates a ton of files, would cause it to take 45-60 seconds for the public website to show up (because it’s recursing through all those files). I’m not sure if this is something that you even control in the plugin or if perhaps it’s more of a general WordPress thing that can’t be changed.
Thanks!
-Mark

Hi Mark,

Are you absolutely sure that this is what is happening here… that the website is recursing through that directory? I think if anything this is a case for Apache and the server itself… if it’s using the /tmp directory for anything and there are 180,000 files in there, it’s definitely likely to slow it down. So it’s not that WordPress is looking at that directory or the files, it’s that your webserver is using the folder and its mass of content slowing down disk/file system lookups.

That’d be my take on it…

Cheers,
Paul.

Hi Mark,

I’ve been investigating this issue and it came up with our iControlWP plugin too. It turns out, it seems, that the WordPress Filesystem object when it is configured to use FTP also reads files from disk using FTP.

In my opinion this is somewhat flawed because if you couldn’t read from disk using direct disk method you couldn’t load a single PHP file.

So with v4.2.1 I’ve worked around this issue to load the plugin files using PHP and this should prevent .tmp files being created.

This also raises another issue with WordPress FTP filesystem in that it doesn’t clean up after itself properly.

Anyways, I’d be keen to here if 4.2.1 works better for you in this regard and it will go a long way to fixing the performance of the site too since it wont use WordPress FTP to load plugin data.

Hope that helps!
Paul

Thanks again Paul! I won’t be working on our websites much over the holidays, so I’ll give this a shot in early January and circle back.

Hey… have you had a chance to check this out? Since the change I’ve heard of nothing more about this problem…

Hey Paul, sorry for the delay in getting back to you. I can confirm that the tmp folder is clean after the latest update! Thank you!

Great, thanks for letting me know! ??