laravel / homestead

MIT License
3.87k stars 1.44k forks source link

Laravel app throwing Facade Root Exception after running vagrant reload #1178

Closed mccordgh closed 5 years ago

mccordgh commented 5 years ago

Posting this per @svpernova09 's advice from a laracasts post (linked at bottom)

Versions

Host operating system

OS X Mojave 10.14.5

Homestead.yaml

ip: 192.168.33.50
memory: 4096
cpus: 1
provider: virtualbox
authorize: ~/.ssh/id_rsa.pub
keys:
    - ~/.ssh/id_rsa
folders:
    -
        map: ../
        to: /home/vagrant/code
sites:
    -
        map: my-app.test
        to: /home/vagrant/code/web/public
databases:
    - homestead
name: web
hostname: web

Vagrant destroy & up output

vagrant destroy gist

vagrant up gist

Expected behavior

After vagrant --reload or a vagrant halt && vagrant up I should be able to access my web app at my-app.test.

Actual behavior

  1. After vagrant --reload or a vagrant halt && vagrant up, I get this error screen when trying to navigate to my-app.test: Screen Shot 2019-06-03 at 12 05 26 PM

If I run (from OUTSIDE the vagrant box): $ php artisan cache:clear $ php artisan route:cache $ php artisan config:cache $ php artisan view:clear I can get "past" this error screen, but then get a new one saying that "[...]/storage/logs" does not exist and could not be built: Permission Denied: Screen Shot 2019-06-03 at 12 11 14 PM

If I try to run any of those cache clearing commands from INSIDE vagrant (after vagrant ssh), I get this error:

Screen Shot 2019-06-03 at 12 12 11 PM

Permissions seem to be a false flag as I've tried changing permissions, etc and the directory definitely does exist.

I haven't found anyway to get any further besides doing vagrant destroy && vagrant up again. But, of course, the errors begin again anytime I do a vagrant reload or vagrant halt && vagrant up or restart my machine, etc.

Steps to reproduce

  1. $ vagrant up to bring box up
  2. Navigate in browser to your box's mapped url
  3. Verify everything is working correctly
  4. Run $ vagrant reload or $ vagrant halt && vagrant up
  5. Navigate in browser to your box's mapped url again.
  6. Facade Root error should appear.

References

I arrived here through these links:

  1. https://laracasts.com/discuss/channels/laravel/laravel-app-throwing-exception-after-running-vagrant-reload?page=1
  2. https://github.com/laravel/homestead/issues/1174#issuecomment-498104987
svpernova09 commented 5 years ago

First thing to try would be changing your folder mounts:

folders:
    -
        map: ../
        to: /home/vagrant/code

To

folders:
    -
        map: /Full/Path/To/Code/Project
        to: /home/vagrant/code
mccordgh commented 5 years ago

@svpernova09 Ah I will do that. This project was setup by someone else and I didn't realize that might be an issue there, as it has worked for a few months that way.

Thanks!


It seems like changing ../ to the full path /Users/matthewmccord/Work/my-app still has the same issues. After a vagrant destroy && vagrant up it works fine, but once I vagrant reload I still get the Facade Root error screen.

Here are screenshots of permissions if this will help (as I said before I only get an error trying to clear cache while INSIDE vagrant (via vagrant ssh): OUTSIDE vagrant: Screen Shot 2019-06-03 at 12 57 14 PM

INSIDE vagrant (via vagrant ssh):

Screen Shot 2019-06-03 at 12 57 24 PM
svpernova09 commented 5 years ago

After a vagrant destroy && vagrant up it works fine, but once I vagrant reload I still get the Facade Root error screen.

This sounds like we're on to something.

Show me the full output of the following:

vagrant destroy -f && vagrant up && vagrant reload

Don't mess with permissions inside the VM on mounted folder shares. You'll only confuse yourself, Virtualbox, and Vagrant. And none of you will enjoy it.

mccordgh commented 5 years ago

@svpernova09 Yea, I definitely don't want to tinker with perms there haha.

So I ran this: vagrant destroy -f &> vagrant_destroy_up_reload.log && vagrant up >> vagrant_destroy_up_reload.log && vagrant reload >> vagrant_destroy_up_reload.log

and here is the output: vagrant_destroy_up_reload gist

Is this what you are looking for?

svpernova09 commented 5 years ago

So there are no services failing, nothing throwing errors, I would have to assume this is a problem with your code base and not Homestead.

mccordgh commented 5 years ago

@svpernova09 should I have run the logging with the --debug flag?

I think some errors aren't reported without it, yea?

svpernova09 commented 5 years ago

I don't think --debug would help. From the logs, Vagrant is working and everything seems to be fine.

svpernova09 commented 5 years ago

Is there anything in /var/log/nginx/ for the site? might give you more info, but I would backtrace the Laravel stack trace at this point.

mccordgh commented 5 years ago

@svpernova09

$ less /var/log/nginx/my-app.test-error.log seems to be the Facade Root error info:

2019/06/04 00:36:07 [error] 1019#1019: *1 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught RuntimeException: A facade root has not been set. in /home/vagrant/code/web/vendor/laravel/framework/src/Illuminate/Support/Facades/Facade.php:234
Stack trace:
#0 /home/vagrant/code/web/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php(397): Illuminate\Support\Facades\Facade::__callStatic('replaceNamespac...', Array)
#1 /home/vagrant/code/web/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php(374): Illuminate\Foundation\Exceptions\Handler->registerErrorViewPaths()
#2 /home/vagrant/code/web/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php(289): Illuminate\Foundation\Exceptions\Handler->renderHttpException(Object(Symfony\Component\HttpKernel\Exception\HttpException))
#3 /home/vagrant/code/web/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php(188): Illuminate\Foundation\Exceptions\Handler->prepareResponse(Object(Illuminate\Http\Request), Object(Symfony\Component\Http" while reading response header from upstream, client: 192.168.33.1, server: stewart.test, request: "GET /live-rides HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.3-fpm.sock:", host: "stewart.test", referrer: "http://stewart.test/notifications"

$ less /var/log/nginx/error.log shows nothing.


Diving in to the Laravel source, I notice that symfony's Finder isn't returning any files for the config path: vender/laravel/framework/src/Illuminate/Foundation/Bootstrap/LoadConfiguration.php

Line 82: method getConfigurationFiles()

Finder::create()->files()->name('*.php')->in($configPath)

The foreach isn't even being executed because Finder::create()->files()->name('*.php')->in($configPath) is returning [] instead of an array of config files...

The var $configPath is correct "/home/vagrant/code/web/config"

Somehow it's just not able to access the files or something??

The only entries in my log file at storage/logs/laravel-2019-06-03.log are for a stack trace due to an error caused by not running migrations before trying to access the db.

svpernova09 commented 5 years ago

Really odd stuff.

Here's something I'd try:

Clone a FRESH copy of the project and set it up, don't change any permissions at all. Spin up a new Homestead box and see if you get the error.

All of the project files in any folder you map through Vagrant should be owned by the user you run the vagrant command as and will be assigned the same permissions to the vagrant user inside the VM.

/cc @driesvints does this issue sound like permissions related? I've ruled out Homestead as much as I can.

driesvints commented 5 years ago

@mccordgh are you using Lumen? Did you enable $app->withFacades(); in your bootstrap.php? Does the app run with Valet? Can you upload a repo with the app which reproduces the problem?

driesvints commented 5 years ago

@svpernova09 I'm not sure. What sync driver is being used by default? NFTS?

svpernova09 commented 5 years ago

I'm not sure. What sync driver is being used by default? NFTS?

Looks like the default Virtualbox, which means any permissions existing on the shared filesystem BEFORE vagrant up will be translated exactly into the VM.

mccordgh commented 5 years ago

@svpernova09 created a dir called fresh_test and cloned the repo for the project in to this new dir, and did all the setup.

After first vagrant up everything worked as expected.

After first vagrant reload same Facade Root error: Screen Shot 2019-06-04 at 8 55 55 AM

Pretty much what I expected, as I've nuked my local repo before and set it all back up trying to see if that would fix things as well. Same thing happened as above, first up was great, on a reload broken.


@driesvints I'm using a full install of Laravel 5.8.

I've been building this project for a clients for several months now, and never had a single issue with reloading vagrant until last week all of a sudden.

Tried to setup Laravel Valet, and I'm just getting 404 - Not Found from that. It's my first time using Valet, so I may be doing something wrong. It seems pretty straight forward though... I have a top level dir my-app (this is the top level repo dir) which holds a few projects within it. web folder is the laravel project

my-app/
+
+-- web/
+
+-- other_project/

I installed valet via composer and valet install, navigated to my-app ran valet park then tried to navigate to http://web.test but I get 404 - Not Found :/

using php -S localhost:8002 from my public/ dir I can get the login screen to appear, but it wont do much beyond that because Laravel needs to be involved I guess.


This seemed to start around the time I updated from OS X Mojave 10.14.4 to 10.14.5 The change notes for 10.14.5 are pretty short and the only thing I can think of that maybe could be affecting things might be kernel extensions related, but I have no idea if any of this is using kernel extensions

OS X Mojave 10.14.5 change notes

After the Mojave update, I also updated Laravel from 5.7 to 5.8, VirtualBox, Homestead from 7.x to newest 8.x

I don't think it was the Mojave update, just that the Mojave update needed me to restart my machine, which brought down vagrant and then when I brought it back up I was getting the Facade Root error.

(And as I mentioned earlier, clearing the cache can get me past Facade Root error, but then I just get a permissions error on storage/logs which seems to be a false flag?)


EDIT: Using php artisan serve with the vagrant box up and just acting as a mysql server, everything works as expected on first vagrant up AND after vagrant reload!!

svpernova09 commented 5 years ago

Try using the latest stable, non-alpha release of Homestead, Should be Homestead v8.5.4, and base box v7.2.1

svpernova09 commented 5 years ago

Does the facade code work if you drop only enough of that code into a new project?

laravel new test-homestead
cd test-homestead
composer require laravel/homestead
php vendor/bin/make
<Add laravel facade code>
vagrant up

That will spin up a new project and Homestead

mccordgh commented 5 years ago

@svpernova09 I followed the docs here to update homestead: https://laravel.com/docs/5.8/homestead#updating-homestead

  1. vagrant box update results in:

    ==> web: Checking for updates to 'laravel/homestead'
    web: Latest installed version: 8.0.0-alpha2
    web: Version constraints: >= 7.2.1
    web: Provider: virtualbox
    ==> web: Box 'laravel/homestead' (v8.0.0-alpha2) is running the latest version.
  2. changing laravel/homestead to ^8 in composer.json and running composer update, then vagrant box list results in:

    laravel/homestead (virtualbox, 6.3.0)
    laravel/homestead (virtualbox, 7.2.1)
    laravel/homestead (virtualbox, 8.0.0-alpha2)

    (I'm assuming the multiple versions are due to having a few different projects on my machine because I work for an agency) This current project is the only one I've updated homestead with, so I assume it's the v8.0.0-alpha2. I'm not sure 100% how to tell which of those 3 in the list maps to the project in my current dir though. Should laravel/homestead be updating to 8.5.4??

Edit: confirmed my current project is on v8.0.0-alpha2 by $ cat ~/.vagrant.d/data/machine-index/index, pretty printing the json and reading through it:

...
          "extra_data":{  
            "box":{  
               "name":"laravel/homestead",
               "provider":"virtualbox",
               "version":"8.0.0-alpha2"
            }
         }
...

as far as your second post about the facade code, I'm not sure what actual Facade Code is erroring. I'm almost certain it's in the bootstrapping of Laravel as the error seems to be in the nginx my-app-error.log file and not in the laravel log file.

svpernova09 commented 5 years ago

Add version: 7.2.1 to Homestead.yaml and it'll lock you to that version of the base box, for The Homestead version, either use the v8.5.5 tag or check out the release branch and make sure it's up to date

mccordgh commented 5 years ago

@svpernova09

I added version: 7.2.1 to my Homestead.yaml I updated composer.json to "laravel/homestead": "^8.5.5" I rancomposer update I ranvagrant destroy -f && vagrant up Still the same v8.0.0-alpha invagrant box list`

The docs say

If you cloned the repository you can run the following commands at the location you originally cloned the repository:

But I just have homestead installed via composer, so I'm not sure if I can do that or what. I'm not sure of how to get my version up past 8.0.0-alpha2 right now :/

ps. Thank you for all of the help so far.

svpernova09 commented 5 years ago

Open composer.json and change the version Homestead is set to dev-release, this will tell composer to pull down the release branch for you, which is always the latest stable tag.

mccordgh commented 5 years ago

@svpernova09 I think we may have found something....

I completely deleted the vagrant box

ran vagrant box update and I'm at v7.2.1 now

set composer.json entry "laravel/homestead": "dev-release"

ran composer update laravel/homestead

ran vagrant up and migrations: everything worked as expected

ran vagrant reload and everything worked as expected

So I guess it is a box v8.0.0-alpha2 issue??

svpernova09 commented 5 years ago

So I guess it is a box v8.0.0-alpha2 issue??

Must be. Which will be fun for me to try to debug. Glad you got it sorted out.

kevinb1989 commented 5 years ago

I have just installed the latest stable today. However, the same issue seems to persist.

randelsr commented 5 years ago

Same here.

I have just installed the latest stable today. However, the same issue seems to persist.

  • Homestead v9.0.0
  • Settler v8.0.0
ksorbo commented 5 years ago

I am having the same problem. Everything was working well with vagrant 2.2.2 and homestead 7.2 My setup vagrant 2.2.5, homestead box 8.0.0 windows 10 This is what I did.

  1. Delete Homestead3 folder. Deleted all homestead boxes (vagrant box remove laravel/homestead --all)
  2. Followed the exact steps to install homestead on the laravel docs page.
    • vagrant box add laravel/homestead ==> laravel/homestead 8.0.0 box downloaded
    • git clone https://github.com/laravel/homestead.git ~/Homestead3
    • cd ~/Homestead3
    • git checkout release
    • composer update
    • init.bat
  3. vagrant up then vagrant ssh then cd in code folder
  4. composer require symfony/finder => composer.,json created correctly
  5. composer update =>>> doesn't throw any errors, BUT NO symfony folder in vendor

This has to be a permissions related error in homestead

In my other project, I created a simple test program with Symfony/Finder `
require('../vendor/autoload.php');

use Symfony\Component\Finder\Finder;

$f = new Finder();
$f->files()->in('../config');
if($f->hasResults()) {
    echo "Has results\n";
}else{
    die("didn't get anything");
}
foreach ($f as $file) {
    $absoluteFilePath = $file->getRealPath();
    $fileNameWithExtension = $file->getRelativePathname();
    echo "$absoluteFilePath => $fileNameWithExtension\n";
}`

When I run this on my laptop, it returns the folder content as intended. When I run it via virtual homestead (either web host or via ssh commandline,), it fails

It seems to be a permissions error in homestead. All file permissions look correct ( drwxrwxrwx 1 vagrant vagrant 0 Jul 6 20:03 ./ drwxr-xr-x 12 vagrant vagrant 4096 Jul 6 20:42 ../ -rwxrwxrwx 1 vagrant vagrant 60 Jul 6 19:59 composer.json -rwxrwxrwx 1 vagrant vagrant 2204 Jul 6 19:59 composer.lock drwxrwxrwx 1 vagrant vagrant 0 Jul 6 20:01 public/ drwxrwxrwx 1 vagrant vagrant 0 Jul 6 20:04 vendor/

Can't be a nginx problem because I get the Finder loading problem even from the CLI (Vagrant destroy && vagrant up gist) https://gist.github.com/ksorbo/c656ca3517d02cf4b123ed4a0939f0fa

ksorbo commented 5 years ago

@svpernova09 I think we may have found something....

set composer.json entry "laravel/homestead": "dev-release"

I can't find where this setting is at. Is this in the Laravel project composer.json? I am using a global Homestead folder and it has no require entry for laravel/homestead

svpernova09 commented 5 years ago

Please stop adding into this thread with "me too" or "same issue here", this isn't helpful. Please open new issues and show the FULL log of vagrant destroy && vagrant up and the rest of the issue template. It's really difficult to debug without a full report.

ghost commented 5 years ago

As many others, I have also had this problem for a little while now. Now, after reading this thread, i got my homestead working again, but I had to go all the way back to version homestead version 8.6.0, or else it will download a homestead box 8.0.0 that does not work either... If you use dev-release as mentioned in this thread, it will try and download box version 8.0.0, and then I get the error.

So what I did was:

so now I am running on box version 7.2.1 - and it is working (the last working version i have tried so far)

Hope this helps anyone

svpernova09 commented 5 years ago

@dennis-nielsen

If box 8.0.0 doesn't work for you, and you're using Virtualbox 6, please post an issue with the details. Rolling back to old versions helps no one, and makes it harder on me to help people. Users should be keeping up to date with the latest versions of the repo and the base box.

ghost commented 5 years ago

@svpernova09 I know it doesnt help finding the issue, but it helps me getting past it so I can continue on my project.

You mentioned Virtual box 6? Actually I am on version 5.2.30 because I remember having other problems with vagrant on version 6. Maybe I should try version 6 again

svpernova09 commented 5 years ago

@svpernova09 I know it doesnt help finding the issue, but it helps me getting past it so I can continue on my project.

Trust me I know! Sometimes you gotta pay the bills first. I get it.

You mentioned Virtual box 6? Actually I am on version 5.2.30 because I remember having other problems with vagrant on version 6. Maybe I should try version 6 again

We've been supporting Virtualbox 6 for a while now, and it looks like v8.x/v9 is the hard cutoff that we're not able to support v5 anymore. I wish I could plan for that better, but it's pretty difficult to track that info.

BinaryBlock commented 5 years ago

@dennis-nielsen

If box 8.0.0 doesn't work for you, and you're using Virtualbox 6, please post an issue with the details. Rolling back to old versions helps no one, and makes it harder on me to help people. Users should be keeping up to date with the latest versions of the repo and the base box.

I was experiencing same problem in this thread, but was still on VirtualBox 5.2.30 on Mac OS.

I upgraded to VirtualBox 6 and now everything is working!! Thank you!