0

I'm having this strange issue on php7.4 and php8.1 on windows11 (apache2.4) where my craft sites loose or fail to load the .env data on some requests and only when under load / handling requests in very fast succession.

I have recorded a video that demonstrates the issue, its about 5 minutes, if anyone can peep this and let know if you have any idea what is going on I'm all ears.

https://vimeo.com/734538875/a34e305115

The crux of the issue is that when this problem occurs a 503 is returned because during the bootstrap the craft code is checking if its "installed" by checking the database connection which fails due to the database configuration not being loaded "randomly" on some requests.

My first thought is this has something to do with opcache and it not including the file each time, but I'm not sure why opcache would ever have a version of this file cached where the values were false. Also, I checked my phpinfo() ouptut and the only reference to opcache is the module authors section and its clearly not enabled in my ini file.

Pre-post-epiphany:

I think I solved this and this boils down to an low-level apache MPM issue. I was reading this thread here: https://laracasts.com/discuss/channels/general-discussion/laravel-intermittently-does-not-pull-from-environment-variables-correctly (I know its laravel but the problem is pretty much identical). I use php-fpm on the server so this problem does not occur there so I'm going keep my .env file and load that for '*' and then I'm adding a 'dev' sub-config with the dev server config hard coded to the config file and I'm pretty sure this will fix it.

The only problem I'm foreseeing here is that I use custom $ENV_VARS for some of my config stuff and I'm not sure how I'm going to deal with that on my local machine and if the code cannot read the ENVIRONMENT variable from the .env I'm not sure how it's going to know it's in 'dev' mode when the problem occurs. I guess I'll have to hard-code something in the /web/index.php file based on the PHP_OS constant or something instead of reading the environment... at least as a fallback.

I'll report back if this fixes the issue for me. I'm still posting all of this as a matter of record, in case someone else runs into this.

EDIT: So my described "workaround" does work as I had hoped but Andrew below dropped the App::env() bomb on me just now so I'm gonna try that next and if that works then that is the answer. I'm guessing at some point craft shipped with getenv() in the config and was later changed to use this wrapper static method, probably to work around problem (maybe anyway). I will report back and accept his answer after I try it out.

1 Answer 1

1

Can you show me your general.php config file? How are you reading in the environment variables?

Probably you should be using App::env() rather then getenv() because it'll attempt to read in the variable from the $_SERVER superglobal first, only falling back on the non-thread safe getenv() if it doesn't find it there:

https://github.com/craftcms/cms/blob/develop/src/helpers/App.php#L81

Example: https://github.com/nystudio107/devmode/blob/develop/cms/config/general.php#L17

GitHub issue: https://github.com/craftcms/cms/pull/5893

ref: https://issuecloser.com/blog/changing-process-environment-unsafe-on-multithreaded-servers

3
  • This site is definitely using getenv() its an older one, was that default before an later changed to use App::env() by default? Interesting development. Jul 30 at 3:24
  • Yes, to fix this exact issue you are having Jul 31 at 4:26
  • Sweet! I guess I missed the patch notes on this when it was introduced. Doh! Aug 3 at 19:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.