apcu not available for local cache is the matching php module installed and enabled
PHP 7 and apcu \OC\Memcache\APCu not available for local cache (Not a duplicate) #21994
Comments
tabp0le commented Jan 28, 2016
I’m aware of the current posted issue with PHP 7 and apcu, #21095, which leads me to this one..
I have PHP 7.0.2 and apcu installed. I installed the patch for incompatibility. OwnCloud loads fine, everything seems to be working, but..
Steps to reproduce
Expected behaviour
No errors in log
Actual behaviour
Errors in log.
OC\HintException: Memcache \OC\Memcache\APCu not available for local cache at /var/www/vhosts/cloud.domain.net/httpdocs/lib/private/memcache/factory.php#94
Info cli Memcache \OC\Memcache\APCu not available for distributed cache 2016-01-28T17:37:48+00:00 Info cli Memcache \OC\Memcache\APCu not available for local cache
Server configuration
Operating system: CloudLinux 6.7
Web server: nginx 1.9.9 & Apache/2.2.15 w/php-fpm enabled
Database: mysql Ver 14.14 Distrib 5.6.26
PHP version: 7.0.2
APCu Version: 5.1.3
ownCloud version: 8.2.2 (stable)
**Updated from an older ownCloud or fresh install:**Update
List of activated apps:
The content of config/config.php:
Are you using external storage, if yes which one: no
Are you using encryption: no
**
Are you using an external user-backend, if yes which one:** No
**
Client configuration**
Browser: Chrome 47.0.2526.111
Operating system: Windows 10
Logs
Web server error log
No errors
ownCloud log (data/owncloud.log)
Browser log
The text was updated successfully, but these errors were encountered:
We are unable to convert the task to an issue at this time. Please try again.
The issue was successfully created but we are unable to update the comment at this time.
APCu not available for local cache and LDAP Problem with PHP7 and cron.php #6613
Comments
stefanbenten commented Sep 22, 2017 •
Steps to reproduce
Expected behaviour
If cron.php is executed everything should be fine.
APCu Memcache should be functional as local Memcache.
No Log Entries regarding the LDAP Configuration.
Actual behaviour
Everytime the cron.php is executed the following messages appear in log:
Info | user_ldap | Paged search was not available | 2017-09-22T09:45:01+0200
Info | user_ldap | No paged search for us, Cpt., Limit 500 Offset 500 | 2017-09-22T09:45:01+0200
Info | user_ldap | Looking for cookie L/O 500/0 | 2017-09-22T09:45:01+0200
Info | user_ldap | Paged search was not available | 2017-09-22T09:45:01+0200
Info | user_ldap | No paged search for us, Cpt., Limit 500 Offset 500 | 2017-09-22T09:45:01+0200
Info | user_ldap | Looking for cookie L/O 500/0 | 2017-09-22T09:45:01+0200
Info | cli | Memcache \OC\Memcache\APCu not available for distributed cache | 2017-09-22T09:45:01+0200
Info | cli | Memcache \OC\Memcache\APCu not available for local cache | 2017-09-22T09:45:01+0200
Server configuration
Operating system: Debian Stretch 9
Web server: Apache 2.4.25
Database: MaxScale Galera Cluster MariaDB
PHP version: PHP 7.0.19-1
Nextcloud version: 12.0.3
Updated from an older Nextcloud/ownCloud or fresh install: Fresh Install
Where did you install Nextcloud from: Download from Webpage
Signing status:
No errors have been found.
List of activated apps:
Nextcloud configuration:
<
«system»: <
«instanceid»: «oc7bv2lmnftj»,
«passwordsalt»: «REMOVED SENSITIVE VALUE«,
«secret»: «REMOVED SENSITIVE VALUE«,
«trusted_domains»: [
«cloud.stefan-benten.de»
],
«trusted_proxies»: [
«10.0.0.2»
],
«datadirectory»: «/mnt/cloud/data/»,
«overwrite.cli.url»: «REMOVED SENSITIVE VALUE«,
«htaccess.RewriteBase»: «/»,
«memcache.local»: «\OC\Memcache\APCu»,
«memcache.locking»: «\OC\Memcache\Redis»,
«filelocking.enabled»: «true»,
«redis»: <
«host»: «/var/run/redis/redis.sock»,
«port»: 0,
«timeout»: 0
>,
«dbtype»: «mysql»,
«version»: «12.0.3.3»,
«dbname»: «cloud»,
«dbhost»: «10.0.3.15»,
«dbport»: «»,
«dbtableprefix»: «oc_»,
«mysql.utf8mb4»: true,
«dbuser»: «REMOVED SENSITIVE VALUE«,
«dbpassword»: «REMOVED SENSITIVE VALUE«,
«installed»: true,
«ldapIgnoreNamingRules»: false,
«ldapProviderFactory»: «\OCA\User_LDAP\LDAPProviderFactory»,
«mail_smtpmode»: «smtp»,
«mail_smtpauthtype»: «LOGIN»,
«mail_smtpsecure»: «tls»,
«mail_from_address»: «cloud»,
«mail_domain»: «REMOVED SENSITIVE VALUE«,
«mail_smtphost»: «REMOVED SENSITIVE VALUE«,
«mail_smtpport»: «25»,
«updater.secret»: «REMOVED SENSITIVE VALUE«,
«maintenance»: false,
«theme»: «»,
«loglevel»: 1
>
>
Are you using external storage, if yes which one: no
Are you using encryption: not yet
Are you using an external user-backend, if yes which one: Active Directory
LDAP configuration (delete this part if not used)
+——————————-+———————————————————————————————————————————————————————————————+
| hasMemberOfFilterSupport | 1 |
| hasPagedResultSupport | |
| homeFolderNamingRule | attr:cn |
| lastJpegPhotoLookup | 0 |
| ldapAgentName | CN=Administrator,OU=Domänenbenutzer,DC=ad,DC=stefan-benten,DC=de |
| ldapAgentPassword | *** |
| ldapAttributesForGroupSearch | |
| ldapAttributesForUserSearch | |
| ldapBackupHost | |
| ldapBackupPort | |
| ldapBase | DC=ad,DC=stefan-benten,DC=de |
| ldapBaseGroups | dc=ad,dc=stefan-benten,dc=de |
| ldapBaseUsers | ou=Domänenbenutzer,dc=ad,dc=stefan-benten,dc=de |
| ldapCacheTTL | 600 |
| ldapConfigurationActive | 1 |
| ldapDefaultPPolicyDN | |
| ldapDynamicGroupMemberURL | |
| ldapEmailAttribute | mail |
| ldapExperiencedAdmin | 0 |
| ldapExpertUUIDGroupAttr | |
| ldapExpertUUIDUserAttr | |
| ldapExpertUsernameAttr | cn |
| ldapGidNumber | gidNumber |
| ldapGroupDisplayName | cn |
| ldapGroupFilter | (|(cn=Domänen-Admins)) |
| ldapGroupFilterGroups | Domänen-Admins |
| ldapGroupFilterMode | 0 |
| ldapGroupFilterObjectclass | |
| ldapGroupMemberAssocAttr | member |
| ldapHost | REMOVED SENSITIVE VALUE |
| ldapIgnoreNamingRules | |
| ldapLoginFilter | (&(&(|(objectclass=person))(|(|(memberof=CN=Domänen-Benutzer,CN=Users,DC=ad,DC=stefan-benten,DC=de)(primaryGroupID=513))))(|(samaccountname=%uid)(|(mailPrimaryAddress=%uid)(mail=%uid)))) |
| ldapLoginFilterAttributes | |
| ldapLoginFilterEmail | 1 |
| ldapLoginFilterMode | 0 |
| ldapLoginFilterUsername | 1 |
| ldapNestedGroups | 0 |
| ldapOverrideMainServer | |
| ldapPagingSize | 500 |
| ldapPort | 389 |
| ldapQuotaAttribute | cloudquota |
| ldapQuotaDefault | 50GB |
| ldapTLS | 0 |
| ldapUserDisplayName | displayname |
| ldapUserDisplayName2 | |
| ldapUserFilter | (&(|(objectclass=person))(|(|(memberof=CN=Domänen-Benutzer,CN=Users,DC=ad,DC=stefan-benten,DC=de)(primaryGroupID=513)))) |
| ldapUserFilterGroups | Domänen-Benutzer |
| ldapUserFilterMode | 1 |
| ldapUserFilterObjectclass | person |
| ldapUuidGroupAttribute | auto |
| ldapUuidUserAttribute | auto |
| turnOffCertCheck | 0 |
| turnOnPasswordChange | 0 |
| useMemberOfToDetectMembership | 1 |
+——————————-+———————————————————————————————————————————————————————————————+
Client configuration
Browser: Chrome 60
Operating system: Windows 10 and Windows 7
APCu 5.1.2 & PHP7: \OC\Memcache\APCu not usable #21095
Comments
d—j commented Dec 10, 2015
Steps to reproduce
Expected behaviour
ownCloud should use the APCu extension for caching.
Actual behaviour
Error message Memcache \OC\Memcache\APCu not available for local cache Is the matching PHP module installed and enabled?
Reason
The new APCu version drops the APC compatibility layer. The extension is now called apcu.so (instead of apc.so ) and the functions and classes have changed prefixes. There is a compatibility extension ( https://pecl.php.net/package/apcu_bc ) but relying on that would IMHO be too restrictive.
Workaround
Replace lib/private/memcache/apcu.php with the following:
Obviously this is not a fix that can be incorporated into core since it relies on PHP7 & APCu 5.1.2. But it will do as a workaround.
Server configuration
Operating system: Ubuntu 14.04
Web server: nginx 1.9.9
Database: mysql 5.5
PHP version: 7.0 (via https://launchpad.net/
ownCloud version: 8.2.1.4
Updated from an older ownCloud or fresh install: yes
List of activated apps:
The content of config/config.php:
Are you using external storage, if yes which one: no
Are you using encryption: no
Are you using an external user-backend, if yes which one: no
ownCloud log (data/owncloud.log)
The text was updated successfully, but these errors were encountered:
We are unable to convert the task to an issue at this time. Please try again.
The issue was successfully created but we are unable to update the comment at this time.
21.0.3 OC\HintException: Memcache \OC\Memcache\APCu not available #27781
Comments
TP75 commented Jul 3, 2021
Nextcloud 21.0.3.1 (after upgrade from 21.0.2.1)
Debian 10.10 Buster
Apache 2.4
PHP 7.3.27
After the upgrade on my machine there is a condition not appearing in any NC version before:
No logging entry found. This makes the NC cron job unavailable apparently.
No such issue in any version before 21.0.3. All settings in place.
The text was updated successfully, but these errors were encountered:
We are unable to convert the task to an issue at this time. Please try again.
The issue was successfully created but we are unable to update the comment at this time.
andrewheeler82 commented Jul 3, 2021
HuguesDug commented Jul 3, 2021 •
Same problem: I had to switch memcache to redis instead of APcu
In general the update to 21.0.3 went wrong. I had to go for manual install, then, blocked in maintenance mode, then repaired manually and now still strugling with a invalid_hash for core/js/mimetypelist.js.
I should have wait for this upgrade : my install is more or less broken.
I hope next version will fix these install issues.
mstinsky commented Jul 3, 2021 •
I can confirm after upgrading from 21.0.2 to 21.0.3 the cronjob does not seem to run anymore, without showing an error.
Enabling apc.enable_cli = 1 fixes the issue.
BernieO commented Jul 3, 2021 •
TP75 commented Jul 3, 2021
Aha, you provided a more complete solution in this report already. thanks again.
This fix solves the issue on my machine and the NC cron job is available again.
However, there should be a more general fix provided by the NC devs hopefully.
Please note on my machine there was not any upgrade or change to the PHP 7.3.27 installation or the settings provided. This configuration allowed all Nextcloud versions before 21.0.3 running without the a.m. issue.
This points at NC 21.0.3 and some PHP code issue, I presume. Your mileage may vary.
andrewheeler82 commented Jul 3, 2021
Yes, I also received this error with the update from 21.0.2 to 21.0.3. I haven’t changed anything on my system. I have noticed for a long time that the developers no longer have their Nextcloud project under control, errors creep in again and again that somehow nobody notices and as soon as the version is published these errors appear.
andyxheli commented Jul 4, 2021 •
I don’t think this is a bug just meed to add apc.enable_cli=1 to /etc/php/8.0/mods-available/apcu.ini
TP75 commented Jul 4, 2021 •
Thanks @andrewheeler82 and I sadly consent.
Apparently, the new Nextcloud policy is taking from big business now: «It’s not a bug it’s a feature.«
The admin manual has been changed to reflect this change of design only recently, I presume. This seems to be an intentional change to the PHP coding in NC 22 and obviously was backported to NC 21.0.3 without any notice to the community. Please prove me wrong, but this is my picture after reading the below reports which are one month old.
If this is the case, this apparent negligence and way of change from Nextcloud would be especially hurting to community people like me who were running a stable NC environment for years.
BernieO commented Jul 4, 2021
The admin manual has been changed to reflect this change of design only recently, I presume.
Actually, the recommendation to set apc.enable_cli to 1 in the php.ini config file has been added in Dec 2018 and was backported to the documentation of NC13:
nextcloud/documentation@c5fa1b6#diff-48dc187eeb03371b5ad6886b33043bf060884809c1d51a3568c5d29e40e3bf13
andrewheeler82 commented Jul 4, 2021
I look through the documentation at regular intervals. Maybe I missed the apc.enable_cli = 1 change. But really now within a smaller release. Activate something like that and the user looks like a dork.
hardingt commented Jul 5, 2021
Also got bit by this one after upgrading from 20.0.2 to 20.0.3. Adding apc.enable_cli=1 to /etc/php/8.0/mods-available/apcu.ini worked for me as well.
zaku903 commented Jul 8, 2021
Got the same issue after upgraded to 21.0.3 days ago, just solved by increase apc.shm_size in php setting to 64M from default 32M. By adding apc.enable_cli=1 only not work for me.
userofgithub023897 commented Jul 11, 2021
@zaku903 Thank you very much.
This fixed it!
Cron and occ work fine again.
tomasmark79 commented Jul 20, 2021
Debian 10 with ISPConfig ignore website PHP settings, so require to set CLI in config file.
path for 7.3 is:
/etc/php/7.3/mods-available/apcu_bc.ini
add these two lines
apc.enable_cli=1 apc.shm_size=512M
This fix issue. I think that an issue is cause PHP updated with APT.
battosai30 commented Jul 23, 2021
Also got bit by this one after upgrading from 20.0.2 to 20.0.3. Adding apc.enable_cli=1 to /etc/php/8.0/mods-available/apcu.ini worked for me as well.
snowflakeas commented Jul 29, 2021 •
not working for me (running on a synology NAS (not docker)).
PHP Warning: PHP Startup: Unable to load dynamic library ‘mcrypt.so’ (tried: /usr/local/lib/php73/modules/mcrypt.so (/usr/local/lib/php73/modules/mcrypt.so: cannot open shared object file: No such file or directory), /usr/local/lib/php73/modules/mcrypt.so.so (/usr/local/lib/php73/modules/mcrypt.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library ‘mysql.so’ (tried: /usr/local/lib/php73/modules/mysql.so (/usr/local/lib/php73/modules/mysql.so: cannot open shared object file: No such file or directory), /usr/local/lib/php73/modules/mysql.so.so (/usr/local/lib/php73/modules/mysql.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
An unhandled exception has been thrown: OC\HintException: [0]: Memcache \OC\Memcache\APCu not available for local cache (Is the matching PHP module installed and enabled?)
battosai30 commented Jul 29, 2021
not working for me (running on a synology NAS (not docker)).
`
snowflakeas commented Jul 29, 2021
apc.enable_cli=1
not working for me (running on a synology NAS (not docker)).
`
No idea where to find apcu.ini
BottomNotch commented Aug 1, 2021
I’ve been struggling with this for a few hours and finally found my issue. I had php-apcu installed, but I needed php7.3-apcu installed, obviously replace that with whatever version of php you’re using.
chippey5 commented Aug 4, 2021 •
According to #2039 and the linked commit #2040 this issue is solved by using Redis instead of APCu as a memcaching backend.
Note: I had to change to PHP 7.4 for this to work, as using PHP 7.3 prior to this didn’t work in my case.
Edit: APCu does work if you just add apc.enable_cli=1 to /etc/php/7.x/cli/php.ini and restart the web server, although it seems there are mixed recommendations about either using APCu or Redis as the commit and documentation says.
szaimen commented Aug 8, 2021
I suppose the final way to fix the resulting issue will be discussed in #27608
Until thats done, make sure that you configured your server correctly.
buzter commented Aug 9, 2021
Using a Synology DS too and found a possible solution for @snowflakes:
Add a «user_settings.ini» in «/usr/local/etc/php74/cli/conf.d» with the following content:
«extension = apcu.so
[apc]
apc.shm_size = 64M
apc.enable_cli = 1″
Works fine for me. Found this solution in the synology forum (https://www.synology-forum.de/threads/nextcloudhub-21-0-1-und-cron.114219/page-2). Best regards
adrien-n commented Aug 10, 2021
As @chippey5 said, there are mixed recommendations between the commit and the documentation. I am completely lost as to what to do. Using apc.enable_cli seems potentially unsafe (should it be used only with the instance turned off?) and the documentation says to prefer APCu.
I wanted to run an occ command but I guess this is also the reason my nextcloud cron jobs have not run in 4 days (when I updated to the most recent version available). If that’s true, it’s possible that a lot more users are going to notice issues in the coming weeks. Clarifying the documentation would probably avoid a lot of questions.
brettferrell commented Aug 13, 2021
Thanks man, this fixed me as well!
Sieboldianus commented Aug 24, 2021
The issue occured during update from 20.0.12 to 21.0.4
But I should have edited
In this file, I needed to enable the extensions:
Missing memcache class on CLI upgrade #17329
Comments
PVince81 commented Jul 2, 2015
Steps
Expected result
Actual result
Please note that the web UI upgrade works properly.
Versions
The text was updated successfully, but these errors were encountered:
We are unable to convert the task to an issue at this time. Please try again.
The issue was successfully created but we are unable to update the comment at this time.
PVince81 commented Jul 2, 2015
Never mind. user error.
I didn’t properly enable the PHP APCu module.
I tried again with it properly enabled, CLI upgrade worked.
ghost commented Jul 7, 2015
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:
to your apcu.ini or php.ini
PVince81 commented Jul 7, 2015
Yeah, I think that’s part I missed.
ghost commented Jul 7, 2015
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.
RobinMcCorkell commented Jul 11, 2015
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 commented Jul 11, 2015
@Xenopathic Its not only about external services but about the memcaches in cli in general.
RobinMcCorkell commented Jul 11, 2015
ghost commented Jul 11, 2015
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 commented Jul 12, 2015
I got the problem on Debian 8.1 with ownCloud 8.1.0. Although I configured everything as said in the docs:
But when I run that, I get an exception:
I suppose I must deactivate memcache until the bug is fixed?
ghost commented Jul 12, 2015
MightyCreak commented Jul 12, 2015
I’ll try again, but with the appropriate option 😉
DeepDiver1975 commented Jul 12, 2015
Might be a good idea to add a notice in the admin docs that says it is apc. and not opcache..
RobinMcCorkell commented Jul 12, 2015
@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 commented Jul 13, 2015
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.
From my POV we better fail hard then screw up anything.
RobinMcCorkell commented Jul 13, 2015
@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.
ghost commented Jul 13, 2015
Its also not recommended in general to enable memcache for CLI (at least APC/APCu) #17329 (comment)
DeepDiver1975 commented Jul 13, 2015
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.