memcached error - no activities are being shown #23076

Closed
beedaddy opened this Issue Mar 10, 2016 · 12 comments

Projects

None yet

6 participants

@beedaddy

Steps to reproduce

  1. Just go to the activities app

Expected behaviour

Some activities should be shown.

Actual behaviour

No activities are being shown. Instead, I get this error message in the log:
Error 33 interacting with memcached : A BAD KEY WAS PROVIDED\\\/CHARACTERS OUT OF RANGE\

Server configuration

Operating system: Debian 8

Web server: Apache 2.4

Database: PostgreSQL 9.4

PHP version: 5.6

ownCloud version: 9.0.0

Updated from an older ownCloud or fresh install: Update from 8.2.3

Where did you install ownCloud from: tar.bz2 from owncloud.org

Signing status (ownCloud 9.0 and above):

Results
=======
- core
    - INVALID_HASH
        - .htaccess

Raw output
==========
Array
(
    [core] => Array
        (
            [INVALID_HASH] => Array
                (
                    [.htaccess] => Array
                        (
                            [expected] => f40e7ca19cd76ff922ccd164e38f4d73806f66170cafa202fb470be225c813b4b242f4321da8a01bef1329e300acf3d137dbcbff058c501f166a2619031fc651
                            [current] => 7bae810b6f5ca98d062ac9985cac7fb2dc8e22d981ec41e8327e53a5ee7f33017b128bbb4ceefbe665dbd35f7a1ee3a0926c4278aeeeb6d7b4325197be1ed9a9
                        )

                )

        )

)

List of activated apps:

Enabled:
  - activity: 2.2.1
  - announcementcenter: 1.1.0
  - calendar: 1.0
  - comments: 0.2
  - contacts: true
  - dav: 0.1.5
  - documents: 0.12.0
  - federatedfilesharing: 0.1.0
  - federation: 0.0.4
  - files: 1.4.4
  - files_external: 0.5.2
  - files_pdfviewer: 0.8
  - files_sharing: 0.9.1
  - files_texteditor: 2.1
  - files_trashbin: 0.8.0
  - files_versions: 1.2.0
  - files_videoplayer: 0.9.8
  - firstrunwizard: 1.1
  - gallery: 14.5.0
  - news: true
  - notifications: 0.2.3
  - provisioning_api: 0.4.1
  - systemtags: 0.2
  - tasks: true
  - templateeditor: 0.1
  - updatenotification: 0.1.0
Disabled:
  - encryption
  - external
  - user_external
  - user_ldap

The content of config/config.php:

{
    "system": {
        "instanceid": "51adb70420b3a",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "datadirectory": "\/var\/owncloud-data",
        "dbtype": "pgsql",
        "version": "9.0.0.19",
        "dbname": "owncloud",
        "dbhost": "localhost",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "maintenance": false,
        "forcessl": true,
        "loglevel": 2,
        "log_rotate_size": 2097152,
        "theme": "",
        "maxZipInputSize": 1610612736,
        "allowZipDownload": true,
        "trusted_domains": [
            "owncloud.brodbeck-online.de",
            "brodbeck-online.de"
        ],
        "secret": "***REMOVED SENSITIVE VALUE***",
        "appstoreenabled": true,
        "appstore.experimental.enabled": true,
        "filelocking.enabled": "true",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "localhost",
            "port": 6379,
            "timeout": 0,
            "dbindex": 0
        },
        "memcached_servers": [
            [
                "localhost",
                11211
            ]
        ],
        "memcache.local": "\\OC\\Memcache\\APCu",
        "memcache.distributed": "\\OC\\Memcache\\Memcached",
        "trashbin_retention_obligation": "auto"
    }
}

Are you using external storage, if yes which one: local

Are you using encryption: no

Client configuration

Browser: Firefox 44.0.2

Operating system: Arch Linux

@beedaddy

Sorry it might just has been a config problem. I removed the memcached stuff from the config file and it now seems to work.

@LukasReschke LukasReschke added the bug label Mar 10, 2016
@LukasReschke
Member

Related #23076, I'd still say we should really hash / encode the keys.

Problem there: \OCP\ICache::clear has a $prefix parameter 🙈

@LukasReschke LukasReschke reopened this Mar 10, 2016
@blizzz
Contributor
blizzz commented Mar 10, 2016

You can have a plain prefix and hash the rest. That's how I do it in the LDAP backend.

@LukasReschke
Member

You can have a plain prefix and hash the rest. That's how I do it in with LDAP.

Yeah. But I'd really like to have this done in the caching interface itself. And \OCP\ICache::set doesn't has a prefix method. 😕

@nickvergessen
Contributor

Workaround:
store 2 entries per entry:

  1. sha => data
  2. key_sha => real.key

Then in the clear() method loop over all keys, if strpos('key_') === 0 check the value for the prefix. if it matches, call delete for the sha key

@blizzz
Contributor
blizzz commented Mar 10, 2016

Yeah. But I'd really like to have this done in the caching interface itself. And \OCP\ICache::set doesn't has a prefix method. 😕

add new method and deprecated the old one?

UPDATE: ah, breaks it as well. add new interface then :p

@nickvergessen
Contributor

which does not help solving the issue we have now at all

@blizzz
Contributor
blizzz commented Mar 10, 2016

No, that's not a short-term scenario, indeed. Your suggestion would work, while also adding some overhead and increasing complexity. As transitional solution OK.

@nickvergessen
Contributor

Btw in the locking e already do sha1() the path, so maybe we should just do that in the CachedRouter as well. That would fix our issues, and then we should add a warning to the cache method to not allow keys longer then 250 chars?

@nickvergessen
Contributor
diff --git a/lib/private/route/cachingrouter.php b/lib/private/route/cachingrouter.php
index 4c702bb..d6270dc 100644
--- a/lib/private/route/cachingrouter.php
+++ b/lib/private/route/cachingrouter.php
@@ -49,7 +49,7 @@ class CachingRouter extends Router {
     */
    public function generate($name, $parameters = array(), $absolute = false) {
        asort($parameters);
-       $key = $this->context->getHost() . '#' . $this->context->getBaseUrl() . $name . json_encode($parameters) . intval($absolute);
+       $key = $this->context->getHost() . '#' . $this->context->getBaseUrl() . $name . sha1(json_encode($parameters)) . intval($absolute);
        if ($this->cache->hasKey($key)) {
            return $this->cache->get($key);
        } else {
@LukasReschke
Member

@nickvergessen Seems good as an intermediate workaround. Still thinking about what we can do for future releases to prevent this from happening in other places…

@LukasReschke
Member

@DeepDiver1975 Any idea regarding above discussion? Basically if a cache key is somewhat longer it may explode anytime on some setups leading to unexpected behaviour 😕

Also #14950

@PVince81 PVince81 closed this in #23214 Mar 14, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment