Clarification: Is APCu acceptable for memcache.locking?

[joshtrichards]

Is APCu acceptable for usage for transactional file locking under any circumstances we consider "supported"? If it's acceptable, are there caveats?

Background: Last year @linuxserver set a default value of for memcache.locking that utilizes APCu in their Nextcloud image: linuxserver/docker-nextcloud@aaa5539 via linuxserver/docker-nextcloud#317.

This was apparently in response to the performance warning added in v27 (when the database is being used for locking - i.e. when Redis isn't configured): linuxserver/docker-nextcloud#319

The end result is that all LinuxServer image users are now using APCu for transactional file locking rather than the database (unless the admin has explicitly configured Redis). This achieved their goal: no longer a warning about using the database for locking.

But is this a valid configuration?

Our documentation is not 100% clear whether we support the use of APCu for memcache.locking:

• https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/files_locking_transactional.html
• https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/caching_configuration.html

We have fallback code that appears to prefer a NULL_CACHE (over using APCu as a fallback) for locking:

server/lib/private/Memcache/Factory.php

Lines 101 to 103 in f2f1074

	if (!($lockingCacheClass && class_exists($lockingCacheClass) && $lockingCacheClass::isAvailable())) {
	// don't fall back since the fallback might not be suitable for storing lock
	$lockingCacheClass = self::NULL_CACHE;

My understanding is that APCu can maybe work for mod_php and some PHP-FPM operating modes. The key requirement being that the operating mode in-use must permit all processes to use a shared APCu cache. However, even if the application server layer is fine, anything happening at the command-line will not use the same APCu cache (effectively being blind to Transaction File Locking). This could lead to problems in areas like occ files commands (and possibly others) I'd think.

So is APCu acceptable at all? Is it worse - or better - than a NULL_CACHE?

TODO:

• Confirm / get feedback
• Create an issue in docs to track clarification / Clarify the docs in a PR
• If "no": Adding a check that explicitly disallows APCu for memcache.locking even if specified explicitly in the config?
• If "no": Coordinating with LinuxServer to change their image behavior
• If "yes": Should we consider changing our default fallback behavior?

[solracsf]

This answers part of it:

server/config/config.sample.php

Lines 2198 to 2199 in 6cac8d0

	* Because most memcache backends can clean values without warning using redis
	* is highly recommended to *avoid data loss*.

Basically, every time PHP get's restarted, APCu is cleared, so are the locks. This is not the case with Redis by default.

Adding a check that explicitly disallows APCu for memcache.locking even if specified explicitly in the config?

I would say push a warning basically with the same message than above 👍

[kesselb]

#38796 (comment)