Cannot instantiate abstract class ValetDriver

[marcodeluca]

Hey, just updated to php7.4 and getting the following error:

Fatal error: Uncaught Error: Cannot instantiate abstract class ValetDriver in /Users/###/.composer/vendor/laravel/valet/cli/drivers/ValetDriver.php:77 Stack trace: #0 /Users/###/.composer/vendor/laravel/valet/server.php(111): ValetDriver::assign('/Users/###...', '###', '/') # 1 {main} thrown in /Users/###/.composer/vendor/laravel/valet/cli/drivers/ValetDriver.php on line 77

Any suggestions?

[drbyte]

Is this error appearing when loading a site served by Valet? Or is it by running a valet command from the command-line?

What PHP version did you upgrade from?
Did you run composer global update to update related dependencies?
Did you upgrade Valet too?
Did you run brew upgrade too?

What's the output of the following?

sw_vers
valet --version
cat ~/.config/valet/config.json
cat ~/.composer/composer.json
ls -al /etc/sudoers.d/
brew config
brew services list
brew list --versions | grep -E '(php|nginx|dnsmasq|mariadb|mysql|mailhog|openssl)(@\d\..*)?\s'
php -v
which -a php
brew info nginx
brew info php
sudo /usr/local/opt/php/sbin/php-fpm --test
sudo /usr/local/opt/php/sbin/php-fpm -y /usr/local/etc/php/7.4/php-fpm.conf --test
ls -al ~/Library/LaunchAgents
ls -al /Library/LaunchAgents
ls -al /Library/LaunchDaemons

[marcodeluca]

Hey @drbyte thanks for the help. To answer your questions - I upgraded from 7.1 to 7.4. I did composer global update, brew update/upgrade, valet upgrade. When it broke, I did an uninstall and clean install of everything.

I have a directory parked, and I get the fatal error when trying to load a site in the browser. Pinging a .test in terminal works fine, so valet is working. I'm pretty sure its a PHP configuration/permissions/version issue. The only thing I can see is possibly an issue wiith PHP-FPM:

php -v = PHP 7.4.3 (cli) (built: Feb 20 2020 12:23:37) ( NTS )
php-fpm -v = PHP 7.1.33 (fpm-fcgi) (built: Jan 6 2020 22:21:03)

And I see in the LaunchAgents: [email protected]

But, running your tests:

sudo /usr/local/opt/php/sbin/php-fpm --test

NOTICE: configuration file /usr/local/etc/php/7.4/php-fpm.conf test is successful

sudo /usr/local/opt/php/sbin/php-fpm -y /usr/local/etc/php/7.4/php-fpm.conf --test

configuration file /usr/local/etc/php/7.4/php-fpm.conf test is successful

So I'm not sure. I've been using valet for years and it's always worked just by following the instructions. So, other than that, everything seems correct. I've posted the outputs below though in case I missed something:

sw_vers
ProductName: Mac OS X
ProductVersion: 10.14.6
BuildVersion: 18G3020

valet --version
Laravel Valet 2.8.1

valet/config.json
{
"domain": "test",
"paths": [
"/Users/myusername/.config/valet/Sites",
"/Users/myusername/LocalDrive/Sync/DEV"
],
"tld": "test"
}

PHP
PHP 7.4.3 (cli) (built: Feb 20 2020 12:23:37) ( NTS )
/usr/local/bin/php
/usr/bin/php

NGINX

nginx: stable 1.17.8 (bottled), HEAD
HTTP(S) server and reverse proxy, and IMAP/POP3 proxy server
https://nginx.org/
/usr/local/Cellar/nginx/1.17.8 (25 files, 2MB) *
  Poured from bottle on 2020-03-01 at 08:06:25
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/nginx.rb
==> Dependencies
Required: [email protected] ✔, pcre ✔
==> Options
--HEAD
	Install HEAD version
==> Caveats
Docroot is: /usr/local/var/www

The default port has been set in /usr/local/etc/nginx/nginx.conf to 8080 so that
nginx can run without sudo.

nginx will load all files in /usr/local/etc/nginx/servers/.

To have launchd start nginx now and restart at login:
  brew services start nginx
Or, if you don't want/need a background service you can just run:
  nginx
==> Analytics
install: 30,549 (30 days), 107,231 (90 days), 415,936 (365 days)
install-on-request: 29,591 (30 days), 103,130 (90 days), 397,058 (365 days)
build-error: 0 (30 days)

brew info php

php: stable 7.4.3 (bottled), HEAD
General-purpose scripting language
https://www.php.net/
/usr/local/Cellar/php/7.4.3 (517 files, 76MB) *
  Poured from bottle on 2020-03-01 at 08:03:59

From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/php.rb
==> Dependencies
Build: httpd ✘, pkg-config ✘
Required: apr ✔, apr-util ✔, argon2 ✔, aspell ✔, autoconf ✔, curl-openssl ✔, freetds ✔, freetype ✔, gettext ✔, glib ✔, gmp ✔, icu4c ✔, jpeg ✔, libffi ✔, libpng ✔, libpq ✔, libsodium ✔, libzip ✔, oniguruma ✔, openldap ✔, [email protected] ✔, sqlite ✔, tidy-html5 ✔, unixodbc ✔, webp ✔
==> Options
--HEAD
	Install HEAD version
==> Caveats
To enable PHP in Apache add the following to httpd.conf and restart Apache:
    LoadModule php7_module /usr/local/opt/php/lib/httpd/modules/libphp7.so

    <FilesMatch \.php$>
        SetHandler application/x-httpd-php
    </FilesMatch>

Finally, check DirectoryIndex includes index.php
    DirectoryIndex index.php index.html

The php.ini and php-fpm.ini file can be found in:
    /usr/local/etc/php/7.4/

To have launchd start php now and restart at login:
  brew services start php
Or, if you don't want/need a background service you can just run:
  php-fpm
==> Analytics
install: 39,740 (30 days), 121,954 (90 days), 468,390 (365 days)
install-on-request: 36,734 (30 days), 112,731 (90 days), 430,247 (365 days)
build-error: 0 (30 days)

brew config
HOMEBREW_VERSION: 2.2.6
HOMEBREW_PREFIX: /usr/local

[drbyte]

The only thing I can see is possibly an issue wiith PHP-FPM:

php -v = PHP 7.4.3 (cli) (built: Feb 20 2020 12:23:37) ( NTS )
php-fpm -v = PHP 7.1.33 (fpm-fcgi) (built: Jan 6 2020 22:21:03)

And I see in the LaunchAgents: [email protected]

I agree.

I'd suggest deleting that 7.1 LaunchAgent
If brew services list shows it running, then stop it first.
Else delete the launchagent and reboot.

[marcodeluca]

it doesnt show up in brew services list, but the LaunchAgent keeps coming back on launch after deleting it. Looking into how to get rid of those permanently. I'm not 100% sure exactly what the issue is, suprising that I havent figured it out after like 3 hours:)

php-fpm -v
PHP 7.4.3 (fpm-fcgi)

So that seems good now.

php-fpm
NOTICE: [pool valet] 'user' directive is ignored when FPM is not running as root
NOTICE: [pool valet] 'group' directive is ignored when FPM is not running as root
ERROR: Another FPM instance seems to already listen on /Users/marcodeluca/.config/valet/valet.sock
ERROR: FPM initialization failed

But that might be what it's supposed to do I think?

[drbyte]

Valet normally runs FPM as root. So yes it seems like you've got a non-root instance of FPM running, presumably from the wrong/old LaunchAgent.

sudo deleting the launchagent file should be enough to stop it reloading on boot. Was it in the system directory? or was it under your home directory? (note the ~ in the following)

ls -al ~/Library/LaunchAgents
ls -al /Library/LaunchAgents
ls -al /Library/LaunchDaemons

[marcodeluca]

it was in ~/Library/LaunchAgents

I deleted it again, restarting again. Really appreciate the help, going nuts here:)

sudo tail /usr/local/var/log/php-fpm.log
[01-Mar-2020 12:06:18] ERROR: Another FPM instance seems to already listen on /Users/asdf/.config/valet/valet.sock
[01-Mar-2020 12:06:18] ERROR: FPM initialization failed
[01-Mar-2020 12:06:18] ERROR: FPM initialization failed

[drbyte]

Curious about:

which -a php-fpm

On OSX 10.14 I'd expect that to show:
/usr/sbin/php-fpm - which is the native PHP 7.1 binary
/usr/local/sbin/php-fpm - which is the homebrew-linked PHP version

ls -al /usr/local/sbin/php* should expose which actual dir it's symlinked to:
lrwxr-xr-x (users/date) /usr/local/sbin/php-fpm -> ../Cellar/php/7.4.3/sbin/php-fpm

Does yours show more php-fpm binaries?

What's the output of ps aux | grep fpm ?

Oh, and passing -v will give you its version:
/usr/local/sbin/php-fpm -v

[marcodeluca]

Okay the useragent is gone, same problem.

When I do valet restart, "brew services list" shows:
dnsmasq started root ...
mysql started username ..
nginx started root ...
php error root ...

and sudo tail /usr/local/var/log/php-fpm.log still shows:
[01-Mar-2020 12:18:39] ERROR: FPM initialization failed
[01-Mar-2020 12:18:39] ERROR: FPM initialization failed
[01-Mar-2020 12:18:49] ERROR: Another FPM instance seems to already listen on /Users/username/.config/valet/valet.sock

which -a php-fpm
/usr/local/sbin/php-fpm
/usr/local/sbin/php-fpm
/usr/sbin/php-fpm

ls -al /usr/local/sbin/php*
lrwxr-xr-x 1 username admin 32 1 Mar 12:14 /usr/local/sbin/php-fpm -> ../Cellar/php/7.4.3/sbin/php-fpm

ps aux | grep fpm
myusername 13716 0.0 0.0 4268040 784 s001 S+ 12:17pm 0:00.00 grep fpm
myusername 12124 0.0 0.0 4492000 876 ?? S 12:15pm 0:00.00 /usr/local/opt/php/sbin/php-fpm --nodaemonize
myusername 12123 0.0 0.0 4492000 860 ?? S 12:15pm 0:00.00 /usr/local/opt/php/sbin/php-fpm --nodaemonize
myusername 12122 0.0 0.1 4492256 17500 ?? S 12:15pm 0:00.05 /usr/local/opt/php/sbin/php-fpm --nodaemonize

/usr/local/sbin/php-fpm -v
PHP 7.4.3 (fpm-fcgi) (built: Feb 20 2020 12:23:47)

[drbyte]

Let's also check: /usr/local/opt/php/sbin/php-fpm -v

[marcodeluca]

/usr/local/opt/php/sbin/php-fpm -v
PHP 7.4.3 (fpm-fcgi) (built: Feb 20 2020 12:23:47)

[drbyte]

How many *.conf files do you have in your
/usr/local/etc/php/7.4/php-fpm.d
folder?

ls -al /usr/local/etc/php/7.4/php-fpm.d

[marcodeluca]

one - -rw-r--r-- 1 root admin 641 1 Mar 12:22 valet-fpm.conf

[drbyte]

Hm, that's normal.

If there were multiples then the fpm logs talking about another service on the same pool would have more context.

Are you still getting the ValetDriver error?

[marcodeluca]

Yah, exact same error. Cannot instantiate abstract class ValetDriver. FPM initialization is failing, valet restart can't seem to start it and using brew to start PHP doesn't work. Maybe I need to like, wipe everything and install it all again?

[drbyte]

Okay, maybe it's time to get destructive in order to force whatever's "not supposed to be running" to be unable to run, by deleting the configs that it is using.

Do you need multiple PHP versions? Did you have custom PHP configs that you wanted to preserve?

I'd suggest deleting or renaming all your PHP "X.X" version directories in the /usr/local/etc/php directory. All of them.
Then run valet install again, and it'll rebuild the ones it needs. (Might need to run valet use php or valet use [email protected] as well.)

[marcodeluca]

No Im running basic static sites and laravel apps, all out of the box. I'll delete and install again and see how it goes.

[marcodeluca]

same problem. After removing, re-installing valet, using [email protected] and restarting valet I still see this:

[01-Mar-2020 12:37:37] ERROR: failed to load configuration file '/usr/local/etc/php/7.4/php-fpm.conf'
[01-Mar-2020 12:37:37] ERROR: FPM initialization failed

brew services list
php error root /Library/LaunchDaemons/homebrew.mxcl.php.plist

[marcodeluca]

there is no php-fpm.conf in /usr/local/etc/php/7.4 so, heh. Why doesnt this stuff just work:)

Can you tell if this a brew issue or a valet issue?

[drbyte]

That's a different error.
We broke something. Apologies.
(I'm trying to think of shortcuts, but fully deleting the current version config was a bad idea.)
Let's fix it with:
brew remove php (which removes php)
and
valet use php (which also reinstalls php)

[marcodeluca]

Brew was unable to link [php]

[marcodeluca]

valet use [email protected] worked, it's installing now.

[marcodeluca]

heh. Brew was unable to install [[email protected]].

[drbyte]

You could try brew reinstall php -vvv to do it in verbose mode and see more of what's going on and what it's complaining about

[drbyte]

(Now or) Later we can run brew cleanup and brew doctor and even brew services cleanup to tidy things.

[marcodeluca]

only thing I saw in verbose was: Warning: The post-install step did not complete successfully. Otherwise it looks like it was installed. valet use [email protected] worked. But, same fatal php error when trying to view a site...

[marcodeluca]

ERROR: failed to load configuration file '/usr/local/etc/php/7.4/php-fpm.conf'
ERROR: FPM initialization failed

[drbyte]

Warning: The post-install step did not complete successfully.

Were you able to run it manually?

[drbyte]

ERROR: failed to load configuration file '/usr/local/etc/php/7.4/php-fpm.conf'

It should have created that as part of the post-install.

[marcodeluca]

brew postinstall php doesnt work when i run it manually either no.

[marcodeluca]

Warning: The post-install step did not complete successfully
You can try again using brew postinstall php
==> An exception occurred within a child process:
Errno::EACCES: Permission denied @ rb_sysopen - /usr/local/etc/php/7.4/pear.conf

[marcodeluca]

I'm seeing a similar issue here: #865

[drbyte]

Ya, it does feel like a need to chown some things properly for homebrew to be able to do its thing.

[marcodeluca]

strange that this is an issue, never experienced problems with basic stuff like this before. So I should chown what, something in the usr/local/Homebrew directory?

[drbyte]

Ya, I wouldn't have expected this to "suddenly" be an issue either.

An article I had bookmarked suggests this:
sudo chown $(whoami):admin /usr/local && sudo chown -R $(whoami):admin /usr/local

Another article talks about more drastic reinstall of homebrew:
https://digitizor.com/install-homebrew-osx-el-capitan/
... but one key in it is just to use brew cleanup and brew doctor to expose low-hanging fruit.

I'd suggest the chown and the brew cleanup and brew doctor.

[drbyte]

If you haven't done that already, you could
ls -al /usr/local/etc/php/7.4/pear.conf
to see who owns the file. Might be intersting to know.

[marcodeluca]

I think its a mac osx issue: Homebrew/brew#3228

[drbyte]

I think its a mac osx issue: Homebrew/brew#3228

For some maybe. It's not a global problem in my experience.

[marcodeluca]

So: sudo chown -R $(whoami) $(brew --prefix)/*

and I can run the postinstall process now. valet restart same issue, but seem to be making some progress. Will check through things again and maybe restart...

[drbyte]

same issue

Specifics are helpful here.
Do you mean:

• just FPM Init failed?
• or is it Cannot instantiate abstract class ValetDriver?
• or is it Another FPM instance is already running on valet.sock?
• or something else in the logs?

[marcodeluca]

Ok, it's always a little bit different every time we take a few steps:)

SO now, it seems like everything is working, but same ValetDriver issue.

in the browser:

Fatal error: Uncaught Error: Cannot instantiate abstract class ValetDriver in /Users/marcodeluca/.composer/vendor/laravel/valet/cli/drivers/ValetDriver.php:77 Stack trace: #0 /Users/marcodeluca/.composer/vendor/laravel/valet/server.php(111): ValetDriver::assign('/Users/marcodel...', 'screenhouse', '/') # 1 {main} thrown in /Users/marcodeluca/.composer/vendor/laravel/valet/cli/drivers/ValetDriver.php on line 77

sudo tail /usr/local/var/log/php-fpm.log seems to be working now?

[01-Mar-2020 13:05:30] ERROR: FPM initialization failed
[01-Mar-2020 13:05:30] ERROR: FPM initialization failed
[01-Mar-2020 13:05:38] NOTICE: Terminating ...
[01-Mar-2020 13:05:38] NOTICE: exiting, bye-bye!
[01-Mar-2020 13:05:40] NOTICE: fpm is running, pid 61249
[01-Mar-2020 13:05:40] NOTICE: ready to handle connections
[01-Mar-2020 13:06:09] NOTICE: Terminating ...
[01-Mar-2020 13:06:09] NOTICE: exiting, bye-bye!
[01-Mar-2020 13:06:14] NOTICE: fpm is running, pid 62403
[01-Mar-2020 13:06:15] NOTICE: ready to handle connections

brew services list
chromedriver started marcodeluca /Users/marcodeluca/Library/LaunchAgents/homebrew.mxcl.chromedriver.plist
dbus stopped
dnsmasq started root /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
mysql started marcodeluca /Users/marcodeluca/Library/LaunchAgents/homebrew.mxcl.mysql.plist
nginx started root /Library/LaunchDaemons/homebrew.mxcl.nginx.plist
php started root /Library/LaunchDaemons/homebrew.mxcl.php.plist

[drbyte]

Oh good. Much better!

Back to where we started, but at least don't have rogue other PHP processes running anymore :)

[marcodeluca]

heh, oh yah after being at this for almost 5 hours I feel much better:) I would have thrown my computer out hours ago if it wasnt for your help. Any suggestions for next steps?

[drbyte]

Does this happen on all projects, or just screenhouse?

Which actual Valet Driver is calling ::assign()?

[marcodeluca]

yah all projects. From valet's NGINX log:

[error] 66166#0: *12 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught Error: Cannot instantiate abstract class ValetDriver in /Users/marcodeluca/.composer/vendor/laravel/valet/cli/drivers/ValetDriver.php:7

Im not sure about which driver, I didnt change or touch anything beyond the basic install which always worked. How do I check?

[marcodeluca]

and in case it matters, I have static HTML and laravel apps in my DEV folder (where I did valet park). Both php and html are getting the same driver error.

[drbyte]

Notwithstanding that you've said this is pretty vanilla without customizations, I'm inclined to suspect some sort of incompatible or damaged driver.

The defaults are installed by composer in the .composer subdir.

But Valet lets you customize things by putting additional drivers in your
~/.config/valet/Drivers subdirectory, and also by adding a
LocalValetDriver.php to your individual projects.

Anything custom in your ~/.config/valet tree?

[marcodeluca]

I don't think so -

ls -la ~/.config/valet
total 8
... Certificates
... Drivers
... Extensions
... Log
... Nginx
... Sites
... config.json
... dnsmasq.d
... valet.sock

ls -la ~/.config/valet/Drivers
total 16
... SampleValetDriver.php
... ValetDriver.php

[drbyte]

I'm trying to figure out how the abstract ValetDriver class is getting into the list of classes to load, when it itself is the one loading it:

valet/cli/drivers/ValetDriver.php

Lines 76 to 82 in d6558b9

	foreach ($drivers as $driver) {
	$driver = new $driver;
	if ($driver->serves($sitePath, $siteName, $driver->mutateUri($uri))) {
	return $driver;
	}
	}

It feels like one of its supported overrides contains a copy of the abstract class for some unexpected reason.

[drbyte]

ls -la ~/.config/valet/Drivers
total 16
... SampleValetDriver.php
... ValetDriver.php

Oh -- let's delete (or move to elsewhere) that ValetDriver.php file from there. (I bet it's a copy of the abstract class. Dunno why it's there)

[marcodeluca]

and like that it works. wtf?

So that valetdriver.php wasn't supposed to be there. How it got there, and how valet has worked for the like, 2+ years I've had it if it was there since then...

[drbyte]

and like that it works. wtf?

So that valetdriver.php wasn't supposed to be there. How it got there, and how valet has worked for the like, 2+ years I've had it if it was there since then...

Totally baffles me too.

[drbyte]

Well, we sure went on a wild goose chase.
I wouldn't have expected that in all the different error cases I've encountered.
It doesn't make sense that that file would just suddenly show up there (esp as an Abstract class).

But hopefully you learned a bunch too along the way, about Valet and Homebrew's inner workings.

[marcodeluca]

Well, man can't thank you enough for the help. Unfortunately the 50 messages here probably won't help many people given this is a very random problem. And I think if you break it down, three problems. So in case anyone lands here to look for issues:

1 - Mac High Sierra and beyond, Mojave, might have some permission issues with Homebrew so after updating to PHP7.4 I had to do the following: sudo chown -R $(whoami) $(brew --prefix)/*

2 - brew did not remove some useragent for php7.1 which was causing issues with PHP-FPM, so I had to manually remove stuff to clean it out and get brew and valet working with PHP 7.4

Details above were helpful for all of that. But

3 - there was some miscellaneous ValetDriver.php in the ~/.config/valet/Drivers folder that I have no idea how it got there. It could have been there from 2 years ago when I started using valet and for whatever reason, it didnt cause a problem until updating to PHP 7.4.

@drbyte can't thank you enough!

[drbyte]

Cool. Glad I was able to help.

You can click Close below if you're satisfied that this issue is resolved.

[ouahib-abderrazzak]

Thank you guys for the efforts it did help me too