env file not always loading

[RickKukiela]

I'm using craft3 beta which uses this package to load the config data.

On my main computer its a core i7 (2016 model) with 24gb RAM and a M.2 SSD etc. I do not have any problems loading .env every time.

Our other PC has a a regular SSD, Core2 Quad 2.4ghz and 8gb of RAM

On the other computer every once in a while the .env data fails to load, which causes craft3 to crash due to the database driver value being empty because .env did not load.

Simply refreshing the page causes the error to go away for a while but it always comes back.

An exact replication of that environment does not bug on my PC at all. Aside from the speed difference, the only other difference is the problem computer is running PHP 7.1.3 and I'm running PHP 7.1.0

[kalvn]

Same here, for some reason, once in a while the file is not read and I get message One or more environment variables failed assertions: ENV is missing. (ENV is one of my parameters).

[tomzx]

@RickKukiela What operating system are you using? What is your environment like (apache/nginx, php loaded as module/php-fpm)?

[RickKukiela]

@tomzx Windows 10, easyphp devserver (no docker / virtual machine setup), mariadb running locally, php 7.1

Its apache 2.4 / php 7.1 - I think its just installed as a regular module not php-fpm

I have this same setup on multiple machines and only the old slow machine exhibits this behavior.

[kalvn]

On my side: Solaris, PHP 5.6 Apache 2.4 with mod_php.

[adambanaszkiewicz]

This is caused by putenv() and getenv() functions in PHP. This library uses it to define if env variable already exists and if not - do nothing. I tested it, and I realize that $_ENV variable was filled with values from .env file, but getenv() function always return null.

Maybe there will be a good idea, to add some configuration, to define if the variables from the .env file should be placed only in $_ENV variable, or both in $_ENV and putenv(). And with getting values the same. This should fix the problem, and wasn't cause backwards compatibility.

Sure, You can overwrite values, but sometimes we don't want to do this, and described solution can works.

[dgrosso]

I'm experiencing the same issue when I run multiple concurrent ajax resquests.

My .env file has 15 lines (only 6 of them are variables) but in some of the concurrent requests, my $_ENV is empty after $dotenv->load(). If I make a var_dump($dotenv->load()), it always displays the 15 lines of the .env file, so I think it must be something with the parsing logic. Any ideas?

I'm running on Apache 2.4.29 with PHP 5.6.33
SO: Arch Linux x86_64 4.14.15-1
PC: i5 (7th gen), 8gb RAM, SSD

[adambanaszkiewicz]

I create my own function env() (like PHP's built-in getenv()), and in this function I use only _$ENV global variable to get values. Now, I don't have any problems, but this thing should be fixed in the Library.

[AeonFr]

Believe it or not, using $_ENV didn't do the trick for me. It was weird because only in one API endpoint the env file wasn't loading, and in all the other endpoints it was. Probably the error triggers when a lot of requests go to the server at the same time.

I was able to solve it by recursively trying to load the env file.

function loadEnvRecursive(){
    $dotenv = new Dotenv\Dotenv(__DIR__);
    $dotenv->load();
    if (!isset($_ENV['ROOT_FOLDER'])) // checks a variable that should be loaded
    {
        return loadEnvRecursive(); // if not set, retry ad infinitum
    }
}

loadEnvRecursive();

[GrahamCampbell]

Duplicate of #219.

[sridesmet]

Putenv and Getenv are not thread-safe. This is probably the cause of your issue.

What happens is the following:
1st request: variables are not there -> load
2nd request: variables are there -> do not load
1st request: ends, cleans up variables
2nd request: use variable -> does not exist anymore, cleaned up by 1st request

[GrahamCampbell]

Yes, this library cannot be used in a multi-threaded environment. The issue is well-described in the link I posted. :)

[GrahamCampbell]

I think it's likely the following example will work in a multithreaded environment. This avoids using the adapter that would have called putenv and getenv, which are not threadsafe.

<?php

use Dotenv\Environment\Adapter\EnvConstAdapter;
use Dotenv\Environment\Adapter\ServerConstAdapter;
use Dotenv\Environment\DotenvFactory;
use Dotenv\Dotenv;

$factory = new DotenvFactory([new EnvConstAdapter(), new ServerConstAdapter()]);

Dotenv::create($path, null, $factory)->load();

[tomasvanrijsse]

I've tried this solution and it did solve the issue.
I overlooked the details of the answer however and other packages stopped working because they relied on getenv.
Since we where only experiencing this issue on Windows we only applied this custom list of adapters on Windows.

[GrahamCampbell]

I overlooked the details of the answer however and other packages stopped working because they relied on getenv.

There's no work around for packages that use a function that isn't threadsafe. They should instead update their code to be threadsafe. The $_SERVER variable behaves most closely to getenv.