New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: APCu support gone in 27.0.0 #38796
Comments
The ACPu support is not gone (unless you uninstalled the php extension). The warning is new in Nextcloud 27 to let you know that without configuration, the database locking provider is active. memcache.local or memcache.distributed is not the default for memcache.locking. server/config/config.sample.php Lines 2136 to 2144 in aedb4be
|
ah, thank you. I wanted to avoid Redis (it's a very small instance) and get rid of the warning. I tried It'd be awesome, if one could use the filesystem (with tmpfs in RAM) for that, so no redis install is needed - but I guess that'd be a feature request. |
false => NullCache. The locking provider stores the data to the null cache instance. I guess that's filelocking.enabled => false without a warning. Your decision if you want to run such a setup.
We will not implement a cache adapter using a local or remote filesystem. |
So it sounds like it is a hazard for data corruption and not just a performance issue. The silenced warning might be a separate issue, then.
Except that it has a track record of security issues and adds overall complexity, thus attack surface. But I guess the devs thought about that. If I'm getting the setup warning right, redis isn't optional anymore as of 27.x, which is why you might want to update the prerequesites in the documentation where redis is mentioned as optional. |
The warning is new. That's the only difference. A contributor with a strong interest in performance optimizations brought to our attention that database locking is slow, and therefore we implemented a warning to inform the administrator about it: #37758 Database locking is also slow for Nextcloud 26, 25, 24, 23, etc. |
The performance is ok for me, the warning is not. Honestly I don't quite get why filelocking isn't using the already configured memcache adapter. It seems to use exactly the same API (?). Is that imposing a risk for data corruption? |
Wondering the same thing. I have a test instance and after adding @heeplr 's memcache.locking suggestion, I too no longer get the error. |
Well observed. local, distributed and locking all require a IMemcache instance. For a single server setup, it's common to configure local and distributed to use the same adapter. If distributed is undefined, local is used as fallback. A setup with multiple nodes often uses memcache or redis to share the distributed cache between the nodes. How is locking different to local and distributed? For cache, it's usually okay if something is not there. Do you think that would work for your locks? ;)
Keep in mind that APCu only works for web request.
Sorry, I don't know. |
I get this warning despite using apcu. The official documentation states that this is ok for small single server. How to disable the warning? What is the correct procedure now? I want the green tick again and not an error/warning message for something that is optional. This isnt like not wearing a seatbelt warning. This is a performance optimization message. There should be a way to disregard it and have the green tick. EDIT: there a good and simple instructions to setup redis here: https://help.nextcloud.com/t/warning-the-database-is-used-for-transactional-file-locking/164095/3 |
+1 I understand and appreciate the need for this warning on larger instances. However, disabling it should be possible for those running smaller instances. I get that file locking provides a load on the database, but that is fine for a smaller homelab instance. For me installing Redis feels like way overkill. I am happy with the performance now and just want the warning message to go away. |
Any update on this? This silent change would likely have caused a lot, if not most, admins of small Nextcloud instances to "panic", since there was no mention of it. |
It's not an error nor warning. It's an informational level message on the setup checks page. It doesn't appear anywhere else. If you know you're on an instance where you're comfortable with db level locking you can ignore it. For the record, Redis is simpler to install and activate than both your NC web and your db were (and requires minimal resources). And there is zero upkeep. It just... Works. I've interacted with multiple people on the forums that avoided activating Redis for similar reasons. This change nudged them to trying it. It really was no big deal. If you have reasons not to do so or simply still don't want to run it, that's fine. Just adding that tidbit of experience in case it's helpful. |
Sure. I get that. But that's not what it looks like in the interface. It looks like a warning. Yellow icon and all. |
It literally spells "warning". The DOM id of the corresponding icon div is "security-warning-state-warning".
I'm pretty sure you're forgetting people who just get PHP+APCu from their managed host and can't convince their hoster, to add redis to the service. This change is going to make life unnecessarily harder for self-hoster and people without access to redis on their managed host. |
Sounds like there is room for improvement in the UI. But behind the scenes it's definitely not tagged as an error or warning, just informational: Lines 234 to 239 in 8f4614b
Good point.
Yes that seems an undesirable side effect. Perhaps a config option similar to this is justifiable: The code change would be straightforward if someone feels like testing and submitting a PR. The code change would be here:
And the code - if you wanted to call the new option
|
Bug description
After upgrading to 27.0.0, administration panel gives a warning, that the database is used for locking transaction files and that I should setup memcache/redis.
I already got APCu configured in config.php:
and it seems to work for other instances running 26.0.2 on the same host/php-fpm.
Steps to reproduce
Expected behavior
No warning / working APCu memcache
Installation method
Community Web installer on a VPS or web space
Nextcloud Server version
27
Operating system
Other
PHP engine version
PHP 8.1
Web server
Nginx
Database engine version
PostgreSQL
Is this bug present after an update or on a fresh install?
Upgraded to a MAJOR version (ex. 22 to 23)
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
No response
The text was updated successfully, but these errors were encountered: