Answers.Body: <p>Can you show me your <code>general.php</code> config file? How are you reading in the environment variables?</p>
  <p>Probably you should be using <code>App::env()</code> rather then <code>getenv()</code> because it'll attempt to read in the variable from the <code>$_SERVER</code> superglobal first, only falling back on the non-thread safe <code>getenv()</code> if it doesn't find it there:</p>
  <p><a href="https://github.com/craftcms/cms/blob/develop/src/helpers/App.php#L81" rel="nofollow noreferrer">https://github.com/craftcms/cms/blob/develop/src/helpers/App.php#L81</a></p>
  <p>Example: <a href="https://github.com/nystudio107/devmode/blob/develop/cms/config/general.php#L17" rel="nofollow noreferrer">https://github.com/nystudio107/devmode/blob/develop/cms/config/general.php#L17</a></p>
  <p>GitHub issue: <a href="https://github.com/craftcms/cms/pull/5893" rel="nofollow noreferrer">https://github.com/craftcms/cms/pull/5893</a></p>
  <p>ref: <a href="https://issuecloser.com/blog/changing-process-environment-unsafe-on-multithreaded-servers" rel="nofollow noreferrer">https://issuecloser.com/blog/changing-process-environment-unsafe-on-multithreaded-servers</a></p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-07-30T03:24:27.043Z
Answers.Text: 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.
Answers.UserDisplayName: Rick Kukiela
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-07-31T04:26:57.867Z
Answers.Text: Yes, to fix this exact issue you are having
Answers.UserDisplayName: andrew.welch
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-08-03T19:16:31.587Z
Answers.Text: Sweet! I guess I missed the patch notes on this when it was introduced. Doh!
Answers.UserDisplayName: Rick Kukiela
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-07-29T00:08:21.053Z
Answers.LastActivityDate: 2022-07-29T00:08:21.053Z
Answers.UserDisplayName: andrew.welch
Body: <p>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.</p>
  <p>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.</p>
  <p><a href="https://vimeo.com/734538875/a34e305115" rel="nofollow noreferrer">https://vimeo.com/734538875/a34e305115</a></p>
  <p>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 &quot;installed&quot; by checking the database connection which fails due to the database configuration not being loaded &quot;randomly&quot; on some requests.</p>
  <p>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.</p>
  <p>Pre-post-epiphany:</p>
  <p>I think I solved this and this boils down to an low-level apache MPM issue. I was reading this thread here: <a href="https://laracasts.com/discuss/channels/general-discussion/laravel-intermittently-does-not-pull-from-environment-variables-correctly" rel="nofollow noreferrer">https://laracasts.com/discuss/channels/general-discussion/laravel-intermittently-does-not-pull-from-environment-variables-correctly</a> (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.</p>
  <p>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 <code>ENVIRONMENT</code> 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 <code>/web/index.php</code> file based on the PHP_OS constant or something instead of reading the environment... at least as a fallback.</p>
  <p>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.</p>
  <p>EDIT:
  So my described &quot;workaround&quot; does work as I had hoped but Andrew below dropped the <code>App::env()</code> 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 <code>getenv()</code> 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.</p>
  
Tags: <config><devmode><env>
Title: .env / config data not loading on repeated / simultaneous requests
ThreadText: # .env / config data not loading on repeated / simultaneous requests
  
  (Asked by: username_0 on 2022-07-28)
  
  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.
  
  **Tags:** config, devmode, env
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2022-07-29. Score: 1 | Accepted answer
  
  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>
  
  > **Comments:**
  > **username_0**: 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.  
  > **username_1**: Yes, to fix this exact issue you are having  
  > **username_0**: Sweet! I guess I missed the patch notes on this when it was introduced. Doh!  
  
  ---
  
  