A while back the redis PHP driver was updated to 4.0.0 and there’s a warning that this release includes API breaking changes.
Thus I’m wondering if it is safe to upgrade to 4.0.0. Will nextcloud still work with redis when I upgrade the driver?
What exactly do you mean by redis driver? The redis-server got an update to version 4 since a while, although It is not yet available on most stale distribution repositories.
But I tested it a while back via stretch-backports on my RPi2 and now I am on Raspbian Buster, running version 4.0.7 without any issues: https://packages.debian.org/buster/redis-server
php-redis module is on 3.1.6 here and there is no version 4.X, not even on upstream, so I guess you mean redis-server: https://packages.debian.org/buster/php-redis
So in short yes! The most current redis server and php module versions run fine with Nextcloud here on my RPi2 as well as VirtualBox testing VM for several months.
But I have to add that I use Redis only for transactional file locking, not for local cache (APCu instead), so can’t say something about that.
What exactly do you mean by redis driver?
I can’t be more specific than that. I mean exactly that: the redis driver for PHP. Or you could call it extension, module, but in the end it’s a driver.
php-redis module is on 3.1.6 here and there is no version 4.
I believe you are mistaken → https://pecl.php.net/package/redis
Here’s the Changelog: PECL :: redis Changelog
Ah yes I am, sorry for that. My last check seems longer ago than I thought.
I will test this on my testing VM 
.
Awesome, thanks.
One of the changes are that connect now throws an exception instead of just returning false on failure. Thus can you please try to enter wrong credentials and see what happens?
I opened a bug with the phpredis devs: https://github.com/phpredis/phpredis/issues/1333
Unfortunately I do not have a complete list of the breaking changes yet.
However, if you point me to the PHP redis code in nextcloud I can have a look at the source.
Just tested the php-redis 4.0.0 version from: https://pecl.php.net/get/redis-4.0.0.tgz
wget https://pecl.php.net/get/redis-4.0.0.tgz
tar -xf redis-4.0.0.tgz
cd redis-4.0.0
phpize
./configure
make
make install
service php7.0-fpm restart
Verify via phpinfo.php that redis module is version 4.0.0: 
Then start redis-cli monitor and do some file upload, moving, removing and watch redis successfully lock and unlock the effected files.
No errors found in nextcloud.log, php7.0-fpm or webserver (Lighttpd) logged, everything seems to work fine 
.
This is great. Which version of nextcloud did you test?
The current stable version 13.0.1
I’m still running 12.0.6, but at least I know that it will work with 13.0.x. I’m going to migrate to 13 in a couple of months.
btw, did you test what happens if the redis connection credentials are wrong? usually if an errror is thown without a catch, a fatal error is produced.
I tested without authentication, just a quick rough test. Will play around with some settings, including password, tomorrow.
You don’t have to setup a password for redis. I don’t want you to go through too much trouble.
But, you could just use a wrong socket name or port number. That should also raise a connection error.
1 Like
Don’t worry, I am interested as well, also to bring automated installation scripts onto current stage for future compatibility in case.
-
Giving wrong redis
host(socket path), inconfig.phpleads to Nextcloud internal server error page and well handled nextcloud.log error:Error index RedisException: No such file or directory /var/www/nextcloud/lib/private/RedisFactory.php - line 84: Redis->connect('/va2r/run/redis...', 0, 0) /var/www/nextcloud/lib/private/RedisFactory.php - line 100: OC\RedisFactory->create() /var/www/nextcloud/lib/private/Memcache/Redis.php - line 42: OC\RedisFactory->getInstance() /var/www/nextcloud/lib/private/Memcache/Factory.php - line 134: OC\Memcache\Redis->__construct('a42f447ce409078...') /var/www/nextcloud/lib/private/Server.php - line 854: OC\Memcache\Factory->createLocking('lock') /var/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php - line 113: OC\Server->OC\{closure}(*** sensitive parameters replaced ***) /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php - line 116: Pimple\Container->offsetGet('OCP\\Lock\\ILocki...') /var/www/nextcloud/lib/private/ServerContainer.php - line 132: OC\AppFramework\Utility\SimpleContainer->query('OCP\\Lock\\ILocki...') /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php - line 164: OC\ServerContainer->query('OCP\\Lock\\ILocki...') /var/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php - line 109: OC\AppFramework\Utility\SimpleContainer->OC\AppFramework\Utility\{closure}(*** sensitive parameters replaced ***) /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php - line 116: Pimple\Container->offsetGet('LockingProvider') /var/www/nextcloud/lib/private/ServerContainer.php - line 132: OC\AppFramework\Utility\SimpleContainer->query('LockingProvider') /var/www/nextcloud/lib/private/Server.php - line 1765: OC\ServerContainer->query('LockingProvider') /var/www/nextcloud/lib/private/Files/View.php - line 114: OC\Server->getLockingProvider() /var/www/nextcloud/lib/private/Server.php - line 193: OC\Files\View->__construct() /var/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php - line 113: OC\Server->OC\{closure}(*** sensitive parameters replaced ***) /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php - line 116: Pimple\Container->offsetGet('EncryptionManag...') /var/www/nextcloud/lib/private/ServerContainer.php - line 132: OC\AppFramework\Utility\SimpleContainer->query('EncryptionManag...') /var/www/nextcloud/lib/private/Server.php - line 1229: OC\ServerContainer->query('EncryptionManag...') /var/www/nextcloud/lib/base.php - line 865: OC\Server->getEncryptionManager() /var/www/nextcloud/lib/base.php - line 737: OC registerEncryptionWrapper() /var/www/nextcloud/lib/base.php - line 1080: OC init() /var/www/nextcloud/index.php - line 35: require_once('/var/www/nextcl...') {main} -
Wrong port (or wrong host as TCP connection) is handled similar.
-
Wrong password works until you actually want to edit some file, then NOAUTH error and well explained nextcloud.log error is thrown as well.
So until now everything is well handled within Nextcloud error pages and throwing self explained nextcloud.log errors.
php-fpm and lighttpd do not show any error as expected, redis-server log (loglevel notice) does not as well (wrong password), which is fine, as long as the client does.
Thank you very much for testing this. However, the question is more an architectural one. How does Nextcloud behave with wrong credentials with the 3.x driver?
Redis is only there to speed up the system, not to be an integral part of the architecture, this means that IMO Nextcloud shouldn’t fail at all when the credentials are wrong, but merely log a warning or show this warning on the Admin page.
What do you think?
I am not sure. Actually redis is not only for speed up, but also for reliability and overall correct function of the locking. For good reason it is highly recommended to use redis for this. ownCloud already shows a warning on admin panel, of redis is not configured, and in my opinion Nextcloud should follow in this. At least files that stay locked due to non-redis locking, is/was one of the most common reasons for support threads here. And I don’t want to know, what is possible, if the MySQL database is totally overloaded by accidentally occurring additional locking requests.
On a production environment for a large company, where databases and everything is well configured for the specific use case, I would want Nextcloud to just stop working/freezing current files state, if redis is somehow not accessible, instead of “silently” switching to MySQL based locking (as it might take a while until one checks the error log, if otherwise everything is working). This way it is guaranteed that during/after maintenance e.g. wrong configured redis is recognized directly and can be fixed, avoiding surprises later on.
Yep, you are right. Totally forgot about the locks. I was just thinking about caching stuff in memory, in which case, should the caching provider not be available, the app is still supposed to work, just without cache.
Locking is a different story, and unless there’s a fallback mechanism, it would be a major problem.
Performance is also a very good point and I agree that APCu and redis are absolutely necessary for larger setups.