PHP 7.2 won't start. Warning: The post-install step did not complete successfully ([email protected], Catalina) #865
Comments
|
Observations:
I think you're not really running Homebrew's PHP, but rather your mac's default PHP. And I wonder if your PATH is properly loading homebrew's binaries before the defaults your Mac comes with. Also, some of the following diags may reveal useful information (EDIT: which are now built-in to sw_vers
valet --version
cat ~/.config/valet/config.json
ls -al /etc/sudoers.d/
openssl version -a
openssl ciphers
php -v
which php
which -a php
nginx -v
curl --version
php --ri curl
brew config
brew doctor
brew info openssl
brew info nginx
brew info php
~/.composer/vendor/laravel/valet/bin/ngrok version
ls -al ~/.ngrok2
sudo nginx -t |
|
@drbyte Thanks for the reply! Apologies I missed updating the commands to what I actually ran after copy/pasting them from that linked issue. I was running Here's the full history of trying it again. I tried a couple different ways to get the brew postinstall step to work but no luck: And still the same error. There must be a configuration still being used somewhere but from only the Output of the remaining commands along with editing the config to have
|
|
So perhaps something above also might have helped, but the key was this warning during That folder didn't exist and it was trying to pull the configuration from it. So I did: which gave no warnings and voila, sites load :) |
|
Good work, and good catch on the missing directory. I'm a little surprised that PHP didn't auto-create the php-fpm.d directory, but I'm glad you made one. You could have just used mkdir, rather than symlinking, as the contents are intended to be volatile. I've an open PR that reworks how the FPM pool config is handled. I'll review it to make sure we create that directory if it's missing though, since that'll save some trouble in the future. You can close this if it's resolved for you. Maybe also update the Title to mention something about @7.2 and Catalina? |
brianhogg
changed the title
|
Moral of the story is treat warnings during Yes, just creating the folder works. You still get a warning when running Marking as closed since it is working for me. Thanks for the help! |
|
@drbyte FYI on the latest version of valet, I'm still getting the same error again when switching back to [email protected]: Not sure why the valet.sock is not loading as there's no logs being generated elsewhere, that I can find. |
|
So it looks like php-fpm is not starting automatically. Switched back to php 7.4, and running php-fpm manually gets valet working: There's no errors or warnings with |
|
Not sure why it didn't start up the new PHP. Maybe it didn't fully shut down the old PHP version properly before switching, which blocked the next one from starting? (if so, the logs would show it trying to start the same pool that's already running.) |
|
Possibly. I'm not sure the best way to check now that brew is updated and After trying again to |
That's puzzling. Not sure why it would stop.
No, that's somewhat normal. Running php from a website runs php-fpm, which is a separate process from the command-line php. FPM runs from the fpm pools linked to nginx, and the CLI runs from whatever paths are linked in your shell session at the time of running it. So, if it's still showing 7.4 from a website, then that indicates that the valet.sock is still fired up by the 7.4 FPM service that got started. And, nginx just reads whatever socket was started. Your troubleshooting requires:
Your extra launchctl entries for PHP might be culprits. I note there's no 7.4 or unversioned php entry there, and that there's duplicate 7.2. Not sure if you expected the 7.1. I'm inclined to clean those up to prevent ambiguity. |
|
Thanks for all the notes! I'm not even able to run brew services at this point: Updated Xcode, ran I've removed the 7.1 entry from launchctl, will try a reboot and see if that helps any. If not, unless you have other suggestions, I'll likely try completely removing valet with the instructions provided by |
|
If you want a thorough cleanup, running You might want to peek in the You can check for other launched apps to be sure nothing unexpected is firing: ls -al ~/Library/LaunchAgents
ls -al /Library/LaunchAgents
ls -al /Library/LaunchDaemonsAfter that a reboot should be much cleaner, and you could begin installing Valet again. Those are some thoughts that might offer additional insights anyway. |
|
After a couple reboots I was hitting an error where the
Despite no errors with Just putting the above in case there's something else a valet restart or install can check for to avoid the bad gateway, but at this point I'll try force uninstalling everything and see how that goes! |
|
brew list shows things like [email protected], but running brew uninstall or brew remove of [email protected] errors with "no such keg" though the Removed Then brew services cleanup returned: Which is interesting that there's still [email protected] and 7.1 hanging around, possibly when I had valet+ installed. Ran: to remove what valet should be managing or not needed at the moment. Will try a reboot and see if anything else lists with |
|
Nothing came up after the above with a However a Running While |
You might try combinations of additional flags to that command, like |
|
Thanks! I didn't realize I thought I had already removed all the /usr/local/etc/php configs before the reboot but must not have. I've uninstalled [email protected] with |
|
Success! Rebooted after ensuring the Thanks again for all the help. Not sure if there's something in the above that can be actioned on to provide additional messaging, but will close this issue as it seems to be all good on a clean install. |
|
Great! I'm glad the root cause has been found and resolved. It may be beneficial to update (again) the title of this issue to be more about the old 7.2 leftover fragments issue than about the 502 gateway issue, since the 502 thing is a very generic symptom vs the root cause. |
brianhogg
changed the title
|
@drbyte no problem! updated the title to reflect the latest thread and root cause. |
|
Having the same problem can someone help? I upgraded the PHP version from |
|
I've now fixed the issue. I found it that when I ran I then ran So, I did Then re-ran, and everything worked like a charm. |
|
FWIW, I had the same exact issue when trying to upgrade to PHP 8. It did not help that I looked at the wrong php-fpm.log file... I was looking in After I chased down the error in the log, I tried removing and reinstalling PHP when I also noticed the warning about |
|
@abhishek-pokhriyal you saved my day! For uncounted hours I was trying to find the reason why PHP 8.1 didn't work, but thanks to your hint to permission issues I got it working. |
After following the instructions on #326 and various other locations, I'm still not able to get valet to serve a page after a successful install. I'm running off
[email protected]as [email protected] errors, and several of the codebases I'm running aren't quite yet ready for 7.4.Commands run:
The brew link was needed as the composer global require fails with:
otherwise.
When trying to visit a configured site I'm seeing this in
~/.config/valet/Log/nginx-error.log:Thinking it might be related to php-fpm (which should be installed automatically with brew install [email protected] and valet install?) I'm seeing this:
At this point I'm stuck. Any help appreciated :)
The text was updated successfully, but these errors were encountered: