RedisException on Upgrade to 8.1.4

[timreeves]

I just upgraded from 8.1.3 to 81.4. (on Ubuntu 12.04) using OC GUI method as Administrator. All went well until the login screen for DB Update, which failed:

RedisException: protocol error, got 'u' as reply type byte

I use Redis (Redis server version 2.2.12) because Plesk 12.5 offers Nginx+FPM with various PHP versions, all very handy, but the only caching module supplied directly is redis.so, so hell, use that. Seems to work fine in normal operation (yes I do have a redis monitor on a dedicated subdomain).

The fallback to CLI Upgrade "php occ upgrade" was successful. Here's the log messages:

{"reqId":"8e2NZjuIJSWGn4SHS6O6","remoteAddr":"178.26.4.226","app":"core","message":"starting upgrade from 8.1.3.0 to 8.1.4.2","level":0,"time":"2015-11-14T10:01:51+00:00","method":"GET","url":"/core/ajax/update.php?requesttoken=Q94igTjc3VUgBaj%2BgsLoTIGbUSATH%2F"} {"reqId":"8e2NZjuIJSWGn4SHS6O6","remoteAddr":"178.26.4.226","app":"update","message":"Exception: {"Exception":"RedisException","Message":"protocol error, got 'u' as reply type byten","Code":0,"Trace":"#0 /var/www/vhosts/gemeinwohl.info/owncloud.lasslos.net/lib/private/memcache/redis.php(74): Redis->get('2885d5d4f71b52c...')n#1 /var/www/vhosts/gemeinwohl.info/owncloud.lasslos.net/lib/autoloader.php(114): OCMemcacheRedis->get('OCPApp')n#2 [internal function]: OCAutoloader->load('OCPApp')n#3 /var/www/vhosts/gemeinwohl.info/owncloud.lasslos.net/apps/files/appinfo/app.php(26): spl_autoload_call('OCPApp')n#4 /var/www/vhosts/gemeinwohl.info/owncloud.lasslos.net/lib/private/app.php(139): require_once('/var/www/vhosts...')n#5 /var/www/vhosts/gemeinwohl.info/owncloud.lasslos.net/lib/private/app.php(120): OC_App::requireAppFile('files')n#6 /var/www/vhosts/gemeinwohl.info/owncloud.lasslos.net/lib/private/updater.php(439): OC_App::loadApp('files', false)n#7 /var/www/vhosts/gemeinwohl.info/owncloud.lasslos.net/lib/private/updater.php(329): OCUpdater->doAppUpgrade()n#8 /var/www/vhosts/gemeinwohl.info/owncloud.lasslos.net/lib/private/updater.php(208): OCUpdater->doUpgrade('8.1.4.2', '8.1.3.0')n#9 /var/www/vhosts/gemeinwohl.info/owncloud.lasslos.net/core/ajax/update.php(93): OCUpdater->upgrade()n#10 {main}","File":"/var/www/vhosts/gemeinwohl.info/owncloud.lasslos.net/lib/private/memcache/redis.php","Line":74}","level":4,"time":"2015-11-14T10:02:05+00:00","method":"GET","url":"/core/ajax/update.php?requesttoken=Q94igTjc3VUgBaj%2BgsLoTIGbUSATH%2F"}

---

BTW: OC keeps telling me "cURL is using an outdated OpenSSL version (OpenSSL/1.0.1). Please update your operating system or features such as installing and updating apps via the app store or Federated Cloud Sharing will not work reliably." ASFAIK the patches to the real bad vulnerabilities like Heartbleed and Poodlebleed are backported on Debian / Ubuntu without changing the version number of the package. Is it still true, the OC message, or may it be misleading in this case?

Cheers, Tim

[thoschl]

I had the same issue here. I logged in an tried to execute "occ upgrade" on the command line. That worked for me. After you are able to log in again, you have to reactivate your apps again.

Best regards Tom

[LukasReschke]

BTW: OC keeps telling me "cURL is using an outdated OpenSSL version (OpenSSL/1.0.1). Please update your operating system or features such as installing and updating apps via the app store or Federated Cloud Sharing will not work reliably." ASFAIK the patches to the real bad vulnerabilities like Heartbleed and Poodlebleed are backported on Debian / Ubuntu without changing the version number of the package. Is it still true, the OC message, or may it be misleading in this case?

Vulnerabilities: Yes. Bugs which break stuff: No.

The error message is thus legit. These older cURL versions do have some problems with SNI.

[timreeves]

@LukasReschke Thanks!

[timreeves]

As some other issues have noted, this problem still exists on Upgrade from 8.1.4 to 8.2.1: Exception: {"Exception":"RedisException","Message":"protocol error, got 'E' as reply type byte\n","Code":0,"Trace":"#0 /var/www/vhosts/.../lib/private/memcache/redis.php(74): Redis->get('49ce4a2952d33ce...')\n#1 /var/www/vhosts/.../lib/autoloader.php(150): OC\Memcache\Redis->get('OCP\\App')\n#2 [internal function]: OC\Autoloader->load('OCP\\App')\n#3 /var/www/vhosts/.../apps/files/appinfo/app.php(26): spl_autoload_call('OCP\\App')\n#4 /var/www/vhosts/.../lib/private/app.php(160): require_once('/var/www/vhosts...')\n#5 /var/www/vhosts/.../lib/private/app.php(141): OC_App::requireAppFile('files')\n#6 /var/www/vhosts/.../lib/private/app.php(1171): OC_App::loadApp('files', false)\n#7 /var/www/vhosts/.../lib/private/updater.php(429): OC_App::updateApp('files')\n#8 /var/www/vhosts/.../lib/private/updater.php(320): OC\Updater->doAppUpgrade()\n#9 /var/www/vhosts/.../lib/private/updater.php(205): OC\Updater->doUpgrade('8.2.1.4', '8.1.4.2')\n#10 /var/www/vhosts/.../core/ajax/update.php(111): OC\Updater->upgrade()\n#11 {main}","File":"/var/www/vhosts/.../lib/private/memcache/redis.php","Line":74} That was again on Ubuntu 12.40 LTS with PHP 5.6.16 and Redis Module 2.2.5.

[PVince81]

Is this still happening with 8.2.2 ?

CC @icewind1991

[timreeves]

@PVince81 can't say: Just updated 2 installations to 8.2.3 but had to do so manually (from tarball), as the Updater in OC did not yet offer the update. Both were on stable channel. Seems funny to me to have to wait so long... or have I overseen something?

[PVince81]

@karlitschek @VicDeo is the stable channel properly delivering 8.2.3 ?

[VicDeo]

@PVince81 8.2.3 should be pushed to stable channel 3 days ago as per https://github.com/owncloud/updater/issues/279#issuecomment-198961386

[PVince81]

@timreeves did it work better with 8.2.3 ?

[PVince81]

If you're still seeing this issue with 8.2.5 or 9.0.2, please reopen.

[shaneonabike]

I found that I had to run occ upgrade twice for this to be completely happy. The first time I got the error and the second time nothing weird

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.