Core: Missing memcache class on CLI upgrade

[PVince81]

Steps

1. Setup OC 8.1RC1
2. Enable APCu memcache (enable the php module and set 'memcache.local' => '\OC\Memcache\APCu' in config.php
3. Go to admin page, see that there is no warning about memcache
4. Switch code to OC 8.1RC2
5. Run CLI upgrade with sudo -uwwwrun ./occ upgrade
   

   Expected result

Upgrade works

Actual result

An unhandled exception has been thrown:
OC\HintException: [0]: Missing memcache class \OC\Memcache\APCu for local cache (Is the matching PHP module installed and enabled ?)

Please note that the web UI upgrade works properly.

Versions

ownCloud 8.1 RC2

@icewind1991 @DeepDiver1975

[PVince81]

Never mind... user error.

I didn't properly enable the PHP APCu module.
I tried again with it properly enabled, CLI upgrade worked.

[ghost]

Just as a follow-up if someone is stumbling over this:

Either you need to enable apcu.so in general for php-cli or you need to add something like:

apc.enable_cli=1

to your apcu.ini or php.ini

[PVince81]

Yeah, I think that's part I missed.

[ghost]

The question is if this is still true for APCu:

Mostly for testing and debugging. Setting this enables APC for the CLI version of PHP. Under normal circumstances, it is not ideal to create, populate and destroy the APC cache on every CLI request, but for various test scenarios it is useful to be able to enable APC for the CLI version of PHP easily.

from https://secure.php.net/manual/en/apc.configuration.php#ini.apc.enable-cli

[Xenopathic]

Hmm, I don't think we should hard-fail on missing memcache for CLI. A missing component (external service unavailable, memcache class not loaded, temporary failures etc) should only affect the production view of ownCloud, aka the web interface and sync interfaces. The CLI should be independent of that, and should work even if there is some (temporary?) disruption to external connected services.

[ghost]

@Xenopathic Its not only about external services but about the memcaches in cli in general.

[Xenopathic]

Precisely - I consider a memcache to be an external service, but this also applies to anything else that ownCloud depends on externally. Example: imagine if at some point ownCloud _requires_ an internet connection, so the web UI will refuse to work if the net goes down. If there is a system problem causing the net outage, and the admin needs to use the CLI to fix it, then the CLI _must_ work even without internet access. All in all, the hard fail modes for the web UI are not the same as the fail modes for the CLI.

[ghost]

Ah, sounds reasonable. In the case of memcache its probably worth to discuss that cli/cron is not using APC/APCu generally as recommended in the quoted docs.

[MightyCreak]

I got the problem on Debian 8.1 with ownCloud 8.1.0. Although I configured everything as said in the docs:

• I installed APCu using the command: sudo apt-get install php-apc
• In /var/www/owncloud/config/config.php: 'memcache.local' => '\OC\Memcache\APCu',
• In /etc/php5/cli/conf.d/05-opcache.ini: zend_extension=opcache.so
• In /etc/php5/cli/conf.d/20-apcu.ini: extension=apcu.so
• In /etc/php5/cli/php.ini: opcache.enable_cli=1
• In /etc/php5/fpm/conf.d/05-opcache.ini: zend_extension=opcache.so
• In /etc/php5/fpm/conf.d/20-apcu.ini: extension=apcu.so
• In /etc/php5/fpm/php.ini: nothing (default)
• Restart php5-fpm and nginx

But when I run that, I get an exception:

sudo -u www-data php occ app:list
An unhandled exception has been thrown:
OC\HintException: [0]: Missing memcache class \OC\Memcache\APCu for local cache (Is the matching PHP module installed and enabled ?)

I suppose I must deactivate memcache until the bug is fixed?

[ghost]

You get that message if php haven't loaded the correct module. Check that with php -i and a phpinfo

[MightyCreak]

Oh sh*t I see where is my problem: I searched for enable_cli and found opcache.enable_cli instead of apc.enable_cli.

I'll try again, but with the appropriate option ;)

Edit It works!
Might be a good idea to add a notice in the admin docs that says it is apc. and not opcache..

[DeepDiver1975]

Might be a good idea to add a notice in the admin docs that says it is apc. and not opcache..

https://secure.php.net/manual/en/apc.configuration.php#ini.apc.enable-cli

^^^ all there :speak_no_evil:

[Xenopathic]

@DeepDiver1975 Let's keep this issue open to track to my comments:

Hmm, I don't think we should hard-fail on missing memcache for CLI. A missing component (external service unavailable, memcache class not loaded, temporary failures etc) should only affect the production view of ownCloud, aka the web interface and sync interfaces. The CLI should be independent of that, and should work even if there is some (temporary?) disruption to external connected services.

[DeepDiver1975]

Hmm, I don't think we should hard-fail on missing memcache for CLI. A missing component (external service unavailable, memcache class not loaded, temporary failures etc) should only affect the production view of ownCloud, aka the web interface and sync interfaces. The CLI should be independent of that, and should work even if there is some (temporary?) disruption to external connected services.

Well - in case of an offline LDAP server we don't want to allow occ operations - because this can have bad side effects - same for an offline Redis/memcached - the behavior is not predictable.

From my POV we better fail hard then screw up anything.

[Xenopathic]

@DeepDiver1975 The thing is, for many operations through CLI a memcache doesn't add anything useful. Our codebase does work without a memcache, it's just slower, and for the single 'request' generated by an occ call performance isn't exactly an issue here.

As for cache invalidation - we have problems as it is with the APCu cache being different between CLI and web, so there isn't much new there.

[ghost]

Its also not recommended in general to enable memcache for CLI (at least APC/APCu) https://github.com/owncloud/core/issues/17329#issuecomment-119251837

[DeepDiver1975]

The thing is, for many operations through CLI a memcache doesn't add anything useful.

This is only true for APCu which separates between CLI and WEB.
Any other memcaches are available and should work.

[MorrisJobke]

Just as a follow-up if someone is stumbling over this:

Either you need to enable apcu.so in general for php-cli or you need to add something like:

apc.enable_cli=1

to your apcu.ini or php.ini

@carlaschroder Can you add this to de documentation? Would be really nice :)

[MightyCreak]

@MorrisJobke Don't we need both? I had apcu.so enabled for php-fpm and php-cli but I still needed to add apc.enable_cli = 1 in the php.ini of CLI.

[MorrisJobke]

I wanted to say, that adding the apc.enable_cli=1 needs to be added to the ini and that should be documented. (the module needs to be loaded in any use case)

[jospoortvliet]

@MorrisJobke but how about the issue with APCu not syncing the cache between CLI and www? See https://github.com/owncloud/core/issues/17329#issuecomment-120884971 (and I recall another issue with more details on this)

[ghost]

Enabling APC/APCu for CLI seems to be also against the recommendation of upstream as already stated here: https://github.com/owncloud/core/issues/17329#issuecomment-119251837

[MorrisJobke]

Okay...but my comment was about the fix for a broken setup. We need to properly disable APCu within the CLI, but for now we need to provide a way to give the users a working occ tool.

[jospoortvliet]

@MorrisJobke ok, if it won't break anything, that's fine... Until a proper fix is in 8.1.1...

[MorrisJobke]

@cmonteroluque I added this to the 8.1.1 because it can break the occ tool if APCu is used.

[DeepDiver1975]

@cmonteroluque I added this to the 8.1.1 because it can break the occ tool if APCu is used.

I see no real necessity to fix this in 8.1.1 - the correct setup is documented. Nothing the user cannot operate around.

[ghost]

the correct setup is documented

The apc.enable_cli=1 is currently not documented in the official docs. Only within a blogpost and the forums.

[MorrisJobke]

The apc.enable_cli=1 is currently not documented in the official docs. Only within a blogpost and the forums.

The backport request is pending. Once it is accepted, we don't need to document this. if not we should add this to the documentation.

[DeepDiver1975]

https://secure.php.net/manual/en/apc.configuration.php#ini.apc.enable-cli

^^^ all there :speak_no_evil:

Seriously - this ^ is enough of documentation. We also can expect users (in this case admin users) to google a bit in case it's not known to them.

[ghost]

I will lead the users at the forums and the IRC channel to you... :hear_no_evil: :grinning:

[MightyCreak]

@DeepDiver1975 I kindly disagree. All the ownCloud administrators don't have to be Linux certified to install it. I consider myself an admin "amateur" and this issue was a problem for me, the documentation wasn't enough and I felt like it should be obvious, but it wasn't.

The PR #17663 simplifies a lot the troubles you can have when you want to follow the documentation advises, so why shouldn't we backport it?

[ghost]

Is it possible to add the configuration: apc.enable_cli = 1 to the main .htaccess file?

there are already some configurations parameters for php that is set with .htaccess file. why not sett this parameter to?

[ghost]

This setting has PHP_INI_SYSTEM:

https://secure.php.net/manual/en/apc.configuration.php

which means you can't use it in your .htaccess:

https://secure.php.net/manual/en/configuration.changes.modes.php