Cache creation generating 'mkdir(): No such file or directory' error message in the logs about wp-rocket HOT 15 OPEN

We need to investigate why it happened in 3.14.1, the AC can be added afterwards

from wp-rocket.

Are we able to reproduce the issue?

I could not find any change in 3.14.1 that would impact the cache creation. The one filesystem-related change is linked to the WPML compatibility, and it's for cache deletion.

I can see some differences between our mkdir_p version and the core one, notably related to permissions, it might be interesting to investigate a change there?

from wp-rocket.

@Tabrisrp I can see similar ticket from the past, not sure why for this specific user it caused a problem after updating to 3.14.1.

@mviniciusbarreto Would it be possible to get access to the affected website, so we could investigate this further?

from wp-rocket.

@Tabrisrp We have access here, with steps.

@rosamillan Could you ask customer if we could investigate this problem on his website?

from wp-rocket.

@Tabrisrp This is not a regression. The issue is more a conceptual issue when your code encounters parallel processing. Like using a web-server-cluster or a WP-Cron runner like Cavalcade which can run parallel processes.

To reproduce: Use the Page Cache "Preload" for a rather big and deep hierarchical page and delete the cache root directory for that page ( wp-content/cache/wp-rocket/<domain> ) from the filesystem while the preload job runs and after it started creating the first child level (like <CACHE-ROOT>/products/services/ ). This will reproduce the scenario where a cache flush will do exactly that and delete the whole directory path. Partly including the cache root for the domain as well.

Your custom recursive mkdir will be at any given level of the page and is not able to create a directory there as the parent directories are missing. Thus the reported warning.
Using the native mkdir with the recursive flag would be able to handle this scenario. It would simply create the missing parent folder hierarchy.

But I belive I wrote most of this in the support tickets already.

from wp-rocket.

I want to add (as one of the reporters), that this wasn't limited to a single version or recent version. These have been showing up in our logs for a very long time. Was easy to ignore them as we found no real damage, but they are making it difficult now to find the other more limited errors as they occur dozens of times per day.

I officially tracked them to WP Rocket about 12 months ago, was hoping they would resolve after some time (updates), due to others reporting them, but alax.

Checking our slack logs (where we send fatal errors), oldest indications are likely in 2020

Context for the image below, I searched this error exactly, sorted oldest first. Popup Maker is in reference to the site it occurred on.

The error messages/logs were identical for each of those to the one I sent in my email report.

from wp-rocket.

Will also add, that my testing required modifying core files to log out statements and make @mkdir not silently error.

Using the native mkdir with the recursive flag would be able to handle this scenario. It would simply create the missing parent folder hierarchy.

In doing so I found that, yes the recurrsive flag in mkdir likely should resolve it. I didn't not test that flag on our live sites wp files, but theoretically it was the primary change I suggested in my ticket.

The other option was using normal mkdir, but checking every parent folder exists and creating them first.

from wp-rocket.

Reproduce the problem

I got the issue but that would be quite complex to reproduce manually as we need to remove the parent folder while it created the parent but not the child yet.
I am still trying to find how to reproduce that.
However I will still provide a solution.

Identify the root cause

The root issue is that we are not ensuring that the parent folder exists before creating the child.

Scope a solution

A solution would be to guard our rocket_mkdir method by checking if the parent exists before writing the child folder.
This way we would have a check that is done in a really close timeframe to the moment it is created.

Tests related to that method should be updated too.

Estimate the effort

Effort XS

from wp-rocket.

I would add that we could check the wp_mkdir_p() to see the differences with our version and updated ours to match if needed.

from wp-rocket.

Another customer is facing similar issues. Apart from the mkdir ones, she is also getting warnings about rmdir and open_basedir.

Slack: https://wp-media.slack.com/archives/C43T1AYMQ/p1692718697448869
HS ticket: https://secure.helpscout.net/conversation/2337094960/438438

from wp-rocket.

Curious if any patches have already been released on this one? I went over changelogs and found nothing that seemed related, but I noticed that we were seeing these dozens of times per day but suddenly none since the 16th. 2 releases seem to be possible in that time-line.

from wp-rocket.

@danieliser We didn't release anything that would be fixing this bug directly. However, the issue could be related to the fact of excessive cache clearing.

@CrochetFeve0251 If we guard rocket_mkdir against this error, we'd still not create the cache in this scenario. Do you see any disadvantages of making sure that mkdir creates directories recursively? Updated the AC there, let's see if we can figure that out

from wp-rocket.

@piotrbak can you explain that in more detail? These errors were occurring even on days nobody logged in to the admin (no cache clearing at least manually).

Also the only viable solution is using mkdir recursively, or manually looping over all folders in the path to check & create if they don't exist. I've tested the mkdir change on our sites already and it does eliminate the issue. So unless there is some side effect I'm not aware of, its the best path forward.

from wp-rocket.

Scope a solution

Another way to solve this issue would be to create our custom Filesystem extending the WordPress one.

For that we will have to do the following class Rocket_Filesystem:

class Rocket_Filesystem extends WP_Filesystem_Direct {
/**
	 * Creates a directory.
	 *
	 * @since 2.5.0
	 *
	 * @param string           $path  Path for new directory.
	 * @param int|false        $chmod Optional. The permissions as octal number (or false to skip chmod).
	 *                                Default false.
	 * @param string|int|false $chown Optional. A user name or number (or false to skip chown).
	 *                                Default false.
	 * @param string|int|false $chgrp Optional. A group name or number (or false to skip chgrp).
	 *                                Default false.
	 * @return bool True on success, false on failure.
	 */
	public function mkdir( $path, $chmod = false, $chown = false, $chgrp = false, $recursive = false ) {
		// Safe mode fails with a trailing slash under certain PHP versions.
		$path = untrailingslashit( $path );

		if ( empty( $path ) ) {
			return false;
		}

		if ( ! $chmod ) {
			$chmod = FS_CHMOD_DIR;
		}

		if ( ! @mkdir( $path, 0777, $recursive ) ) {
			return false;
		}

		$this->chmod( $path, $chmod );

		if ( $chown ) {
			$this->chown( $path, $chown );
		}

		if ( $chgrp ) {
			$this->chgrp( $path, $chgrp );
		}

		return true;
	}
}

Once we did that we will then have to change the filesystem class used inside rocket_direct_filesystem to our new class.

Finally we could get rid of the old logic inside wp_mkdir_p to use our new filesystem.

Estimate effort
Effort S

from wp-rocket.

looks good to me, on the long term having our own Filesystem class was something we always wanted to do, and would help us solve this kind of issues

from wp-rocket.