My Laravel 5 has run OK until the database was configured, then found this error:
SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo failed: Name or service not known
Doing some research it seems that I configured MySQL access too late, so I should restart the server in order to get the correct environment variables. Well, I'm using Dreamhost's shared server and I just can't do that.
How should I fix this issue?
Thanks
If you have run php artisan config:cache
on your server, then your Laravel app could cache outdated config settings that you've put in the .env
file.
Run php artisan config:clear
to fix that.
It's possible that your configuration variables are cached. Verify your config/app.php
as well as your .env
file then try
php artisan cache:clear
on the command line.
In case anybody stumbles upon this question who cannot reload their webserver (long running console command like a queue runner) or needs to reload their .env file mid-request, i found a way to properly reload .env variables in laravel 5.
use Dotenv;
use InvalidArgumentException;
try {
Dotenv::makeMutable();
Dotenv::load(app()->environmentPath(), app()->environmentFile());
Dotenv::makeImmutable();
} catch (InvalidArgumentException $e) {
//
}
A short solution:
use Dotenv;
with(new Dotenv(app()->environmentPath(), app()->environmentFile()))->overload();
with(new LoadConfiguration())->bootstrap(app());
In my case I needed to re-establish database connection after altering .env programmatically, but it didn't work , If you get into this trouble try this
app('db')->purge($connection->getName());
after reloading .env , that's because Laravel App could have accessed the default connection before and the \Illuminate\Database\DatabaseManager
needs to re-read config parameters.
In config/database.php
I changed the default DB connection from mysql to sqlite. I deleted the .env
file (actually renamed it) and created the sqlite file with touch storage/database.sqlite
. The migration worked with sqlite.
Then I switched back the config/database.php
default DB connection to mysql and recovered the .env
file. The migration worked with mysql.
It doesn't make sense I guess. Maybe was something serverside.