PHP container not refreshing script updates in Docker for Windows (WSL2/NTFS regression) about docker-php-fpm HOT 10 CLOSED

Hey Brandtley, if I track correctly your objective is to change PHP runtime settings for opcache.revalidate_freq.
If you take a look at the docker-compose log for php-fpm container, you'll notice that the container is loading php-fpm pool configuration from /config/www.conf

php-fpm    | env PHP_POOL_PATH: copy from [ /config/www.conf ] into [ /usr/local/etc/php-fpm.d/ ] folder
php-fpm    |  - /config/www.conf

you can make those changes there by adding:

php_admin_value[opcache.revalidate_freq] = 1

right there in: /config/www.conf file.

You can further change the Docker PHP-FPM container behavior by using environment settings to point to a different configuration file for PHP pool configuration and php.ini respectively. Hope that helps!

from docker-php-fpm.

@markhilton Right, I figured out the configuration overrides.

I updated my comment with a little more info in my third paragraph above.

My question is that I'm confused that out-of-the box, I can't see my PHP changes in the browser or in my REST Client without physically restarting the PHP-FPM container.

This seems like a really tedious thing to do in a development environment and I'm not sure where to look to resolve this?

I only mention opcache because I found a stackoverflow post where someone mentioned this solving their issue, but it still isn't solving my problem in this instance.

from docker-php-fpm.

@bmcminn that's by design I would say, although technically you could reload services inside Docker container without restarting the entire container. When Docker detects that the main process no longer runs, the container is automatically stopped. If you dig deeper you'll notice that PHP-FPM does not run as a background daemon process inside the container, as in typical PHP-FPM configuration, but as a foreground process for that reason.

You can use docker-compose.yaml to specify behavior in case of the unexpected stop of the container - like automatic restart. If you do that, then you could just execute a kill command inside the container to kill PHP-FPM manager process, forcing the container to restart and load a new configuration. In any case, you need to restart PHP-FPM to load the updated configuration.

There is also another way to force the main process to reload without restarting the entire container, which is a bit faster solution, by executing kill -USR2 1 inside the container. More info here: docker-library/php#399

from docker-php-fpm.

Right, but my issue isn't having to restart PHP-FPM to reload the configuration, it's having to restart PHP-FPM after I make changes to my PHP files to get them to show up in browser.

<?php
// index.php
echo "hello world";

For example, my index.php in app root just echoes hello world and this loads and works fine. However, if I change it to say hello user and save to disk and refresh the page, the server still renders hello world. I have to restart PHP-FPM before my changes get updated in the container and rendered to the browser.

This is the problem I'm having and I don't understand why it's happening since I have a volume configured and I would expect me updating my files on my host disk to be mapped to the container for rapid prototyping.

from docker-php-fpm.

oh, well that has to be something with the cache then. There is no need to restart PHP-FPM to see changes on the page as you update the code. The obvious suspect would be opcache config. I would look into FastCGI or Redis cache if you use any of these in your environment.

I do not see it in your docker-compose.yaml example, but my Nginx docker container has a build-in cache capability, could use local filesystem for this purpose. I would look into the Nginx docker container environment settings. You should also see it during the boot process in the docker logs.

from docker-php-fpm.

@markhilton I figured it out. It's an upstream problem regarding WSL2 support Windows is still missing a solution for the inotify event translation between NTFS and the container itself, and that's why my files aren't synchronizing even though my volumes are technically setup correctly.

microsoft/WSL#4739

I've updated my issue title as well.

Related, I did find some resources for getting around this issue by setting up Ubuntu in WSL for Windows 10 and moving running my project assets/docker processes from there.

https://levelup.gitconnected.com/docker-desktop-on-wsl2-the-problem-with-mixing-file-systems-a8b5dcd79b22

from docker-php-fpm.

Oh wow I bet it took a while, but that's a great inside. I run into similar problem with Mac OS in the past, and also there were some work around solutions out there.

But since, I know Docker introduced additional volume parameters you can use when mounting your local path to a Docker container like ":cached" ":delegated". Did you try any of these with your config?

http://docs.docker.oeynet.com/docker-for-mac/osxfs-caching/#tuning-with-consistent-cached-and-delegated-configurations

from docker-php-fpm.

Yeah, I tried the volume parameters and it still didn't work. It's all the same problem, Windows NTFS can't propagate file change events to the Docker container so it never synchronizes file updates.

from docker-php-fpm.

One work around I haven't considered is formatting a drive as ExFAT and running my volumes off that... No idea if it would work, but I've got a spare 1Gb USB stick I could reformat and give it a shot :P

from docker-php-fpm.

Revisiting this issue, not sure what exactly corrected it, however the following configuration is working as expected:

• Windows 10 pro Build 19042
• Docker for Windows 3.3.3
• WSL2 instance of Ubuntu 18.04

from docker-php-fpm.