Valet-plus: Fatal error: Call to undefined function apcu_fetch()

Created on 13 Apr 2018  路  18Comments  路  Source: weprovide/valet-plus

Having same issue as #133 , followed the suggestions but no luck. Any Suggestions?

Fatal error: Call to undefined function apcu_fetch() in /User/r2d2/.composer/vendor/weprovide/valet-plus/server.php on line 37

env details


php -v
PHP 7.1.16 (cli) (built: Apr 12 2018 03:28:19) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.1.16, Copyright (c) 1999-2018, by Zend Technologies


z-performance.ini

; Add America/New_York string for replacing with machine timezone
date.timezone = "America/New_York"

; Max execution time per request
max_execution_time = 300

; Max memory per instance
memory_limit = 128M

;The maximum size of an uploaded file.
upload_max_filesize = 128M

;Sets max size of post data allowed. This setting also affects file upload. To upload large files, this value must be larger than upload_max_filesize
post_max_size = 128M

session.auto_start = off
session.gc_probability = 0
suhosin.session.cryptua = off
memory_limit=2G

; Disable garbage collector
zend.enable_gc = off

; Use mailhog for sending emails
sendmail_path = /usr/local/bin/MailHog sendmail test@test

[opcache]
opcache.enable = 1
opcache.enable_cli = 1
opcache.memory_consumption = 2048
opcache.interned_strings_buffer = 20
opcache.file_cache=1
opcache.max_accelerated_files = 80000
opcache.max_wasted_percentage = 5
opcache.use_cwd = 1
opcache.validate_timestamps = 1
opcache.revalidate_freq = 0
opcache.file_update_protection = 2
opcache.revalidate_path = 0
opcache.save_comments = 1
opcache.load_comments = 1
opcache.fast_shutdown = 1
opcache.enable_file_override = 0
opcache.optimization_level = 0xffffffff
opcache.inherited_hack = 1
opcache.blacklist_filename = ""
opcache.max_file_size = 0
opcache.consistency_checks = 0
opcache.force_restart_timeout = 180
opcache.error_log = ""
opcache.log_verbosity_level = 1
opcache.preferred_memory_model = ""
opcache.protect_memory = 0
apc.cache_by_default = false

[apcu]
; apcu and php-fpm cause valet to hang, so we turn off apcu for now.
; See https://github.com/weprovide/valet-plus/issues/49
apc.enabled=0
apc.shm_size=512M
apc.ttl=7200
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.enable_cli=1

[xdebug]
xdebug.remote_enable=1
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.remote_autostart=1
xdebug.idekey=PHPSTORM

.


pcel list

Installed packages, channel pecl.php.net:
=========================================
Package Version State
apcu    5.1.11  stable
apcu_bc 1.0.4   stable
geoip   1.1.1   beta

Most helpful comment

I had the same problems as others on here (including having none of the listed workarounds or restarts work). I finally got mine working using:

Verify PHP runs without errors (deal with any errors it complains about. Usually it's something like "syntax error, unexpected '=' in /usr/local/etc/php/7.1/php.ini on line 1" which looks like someone is missing adding a newline when inserting entries at the top of the file).
php -v

Check to see which PHP is running (in my case it showed as: "[email protected] error root /Library/LaunchDaemons/[email protected]")
brew services list

Restart that PHP (note, I didn't use sudo here):
brew services restart [email protected]

All 18 comments

Hi @djdesign - sounds like your valet's frontend is still running on a different PHP version than your cli - could you try rebooting your machine as this seems to solve quite a few issues after updating. Let me know if this helps or if you require extra assistance.

@samgranger I have restarted, but doesn鈥檛 help.

Same problem here, same config.

Currently working on some improvements for this. @djdesign Are the apcu.so lines added to your php.ini file?

@Neodork Yes I see It listed at the top.

extension="apc.so"
extension="apcu.so"
extension="geoip.so"

@djdesign Those are invalid. Remove those and switch back. valet use 5.6 and valet use 7.1. Or did you remove the full path?

@djdesign Did you try run valet install after valet use?

image

After run valet use, i need run valet install for working on new version php.

image

I don't know if that's the correct procedure

This is the results I get.
screen_shot_2018-04-13_at_10_08_00_am

@djdesign Could you show me brew list | grep php

@Neodork

~/s/v/testing $  brew list | grep php
php-cs-fixer
[email protected]
phpunit

The reason you see 7.1 is I switched over 7.1 seeing if anything else changed, but did not change or fix the bug. If I left it with php5.6 then it would show that in the list.

Oke so no old installations present, that's good. How about ls -la /usr/local/etc/php/7.0/cond.d/ are there any ext-apcu.ini files present?

~/s/v/testing$  ls -la /usr/local/etc/php/7.0/cond.d/
ls: /usr/local/etc/php/7.0/cond.d/: No such file or directory
~/s/v/testing  ls /usr/local/etc/php/*/conf.d/
/usr/local/etc/php/5.6/conf.d/:
ext-opcache.ini   z-performance.ini

/usr/local/etc/php/7.0/conf.d/:
ext-opcache.ini   z-performance.ini

/usr/local/etc/php/7.1/conf.d/:
ext-opcache.ini   z-performance.ini

/usr/local/etc/php/7.2/conf.d/:
ext-opcache.ini       php-memory-limits.ini z-performance.ini

I had the same problems as others on here (including having none of the listed workarounds or restarts work). I finally got mine working using:

Verify PHP runs without errors (deal with any errors it complains about. Usually it's something like "syntax error, unexpected '=' in /usr/local/etc/php/7.1/php.ini on line 1" which looks like someone is missing adding a newline when inserting entries at the top of the file).
php -v

Check to see which PHP is running (in my case it showed as: "[email protected] error root /Library/LaunchDaemons/[email protected]")
brew services list

Restart that PHP (note, I didn't use sudo here):
brew services restart [email protected]

I solved this problem by uninstalling PHP and Valet Plus.
When you enter php -v, you shoud have command not found.

Then, reinstall PHP with brew and valet plus.

I've had contact with @djdesign through google hangouts. The problem was mostly related to having PHP-FPM serving an other version of PHP as the CLI. As mentioned in this thread a few times before. He did have some issues with the DB afterwards but I don't think those were related to this issue.

Thanks for helping @djdesign out @Neodork - closing this issue for now.

Thanks @lazyguru, brew services restart [email protected] works!

Was this page helpful?
0 / 5 - 0 ratings