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: homebrew.mxcl.php@7.1.plist

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: openssl@1.1 ✔, 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 ✔, openssl@1.1 ✔, 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: homebrew.mxcl.php@7.1.plist

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 php@7.4 as well.)