Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Disable Scan Directories Feature when restarting #137

Closed
ghost opened this issue Oct 20, 2021 · 3 comments
Closed

Proposal: Disable Scan Directories Feature when restarting #137

ghost opened this issue Oct 20, 2021 · 3 comments

Comments

@ghost
Copy link

ghost commented Oct 20, 2021

I'am using php in a standard docker container FROM php:7.4-fpm which is compiled with --with-config-file-scan-dir

root@dev-6b74fdbbb-gwbnb:/var/www# php -i | grep scan
Configure Command => './configure' '--build=x86_64-linux-gnu' '--with-config-file-path=/usr/local/etc/php' '--with-config-file-scan-dir=/usr/local/etc/php/conf.d' '--enable-option-checking=fatal' '--with-mhash' '--with-pic' '--enable-ftp' '--enable-mbstring' '--enable-mysqlnd' '--with-password-argon2' '--with-sodium=shared' '--with-pdo-sqlite=/usr' '--with-sqlite3=/usr' '--with-curl' '--with-libedit' '--with-openssl' '--with-zlib' '--with-pear' '--with-libdir=lib/x86_64-linux-gnu' '--enable-fpm' '--with-fpm-user=www-data' '--with-fpm-group=www-data' '--disable-cgi' 'build_alias=x86_64-linux-gnu'

This leads to duplicate module loading when the temporary INI-File is generated from php_ini_scanned_files()

if ($scanned = php_ini_scanned_files()) {

I propose that the proc_open call should be provided with the PHP_INI_SCAN_DIR environment variable pointing to an directory containing an empty ini-file to resolve this issue:

$process = proc_open($cmd, array(), $pipes,null,['PHP_INI_SCAN_DIR' => '/tmp/test-scan-dir']);

$process = proc_open($cmd, array(), $pipes);

root@dev-6b74fdbbb-gwbnb:/var/www# ls /tmp/test-scan-dir/ -la
total 24
drwxr-xr-x 2 root root  4096 Oct 20 15:38 .
drwxrwxrwt 1 root root 20480 Oct 20 17:46 ..
-rw-r--r-- 1 root root     0 Oct 20 15:38 empty.ini
root@dev-6b74fdbbb-gwbnb:/var/www# cat /tmp/test-scan-dir/empty.ini 

Note the comment in the PHP Manual:
https://www.php.net/manual/en/configuration.file.php#configuration.file.scan

If a blank directory is given in PHP_INI_SCAN_DIR, PHP will also scan the directory given at compile time via --with-config-file-scan-dir.

Alternatively the temporary INI-File could be stored in a directory and included this why and not by using the -c-Flag:

array_push($php, '-n', '-c', $this->tmpIni);

I've encountered this issue in https://github.com/phpstan/phpstan.

@johnstevenson
Copy link
Member

Have you tried using XDEBUG_HANDLER_DEBUG as per https://github.com/composer/xdebug-handler#troubleshooting to see what is going on?

I've encountered this issue in https://github.com/phpstan/phpstan

Perhaps this is related to #136 which was caused by phpstan doing something with ini files?

Note the comment in the PHP Manual:

The PHP manual is badly worded. What they mean is that a "blank directory" (:) will use the compile-time config. But an empty value disables scanning:

$ php -r 'echo (PHP_CONFIG_FILE_SCAN_DIR), PHP_EOL;'
/etc/php/7.4/cli/conf.d

PHP_INI_SCAN_DIR= php --ini
Configuration File (php.ini) Path: /etc/php/7.4/cli
Loaded Configuration File:         /etc/php/7.4/cli/php.ini
Scan for additional .ini files in: (none)
Additional .ini files parsed:      (none)

However, xdebug-handler only uses PHP_INI_SCAN_DIR if the host requires Xdebug to be disabled for all processes (https://github.com/composer/xdebug-handler#persistent-settings), otherwise by default it uses command line options and -n tells PHP not scan for additional inis.

@ghost
Copy link
Author

ghost commented Oct 20, 2021

@johnstevenson sorry i did not see the -n-Flag - this is of course correct and way better than what i proposed!

Thank you very much for the tip using XDEBUG_HANDLER_DEBUG. Creating a test-script with this gave me a better idea of whats actually going on. phpstan is hiding most of the output of it's worker processes.

My proposal fixed the Issue because phpstan is using \React\ChildProcess\Process which will inherit all environment variables from the parent process.

But phpstan is missing the -n flag on it's workers which could explain the problem because workers should not get restarted when xdebug is already disabled:

                        ❯ pstree -c -p -s -a 2540066
                        systemd,1 --system --deserialize 100
                          └─containerd-shim,1456 -namespace moby -id 152f05fe5d26121e0648223785787a4443f2c2bd85e2200aae35b0e03097d46f -address /var/run/docker/containerd/containerd.sock
                              └─docker-init,1497 -- /bin/k3s server --tls-san 0.0.0.0
                                  └─containerd-shim,6775 -namespace k8s.io -id 0644b5a9143d602b5029b202685c41c2a92caacedb13046007cfc1ba40f24953 -address /run/k3s/containerd/containerd.sock
                                      └─bash,2354967
My Command >                              └─php,2540024 phpstan-src/bin/phpstan
Restarted (by XDebugHandler) >                └─php,2540028 -n -c /tmp/W31pDl phpstan-src/bin/phpstan
Worker ShellWrapper >                            └─sh,2540046 -c '/usr/local/bin/php' -c '/tmp/W31pDl' -d memory_limit=-1 'phpstan-src/bin/phpstan' 'worker' --configuration '/var/www/phpstan.neon' --port 45829 --identifier pgfusrp9ey --
Worker >                                              └─php,2540049 -c /tmp/W31pDl -d memory_limit=-1 phpstan-src/bin/phpstan worker --configuration /var/www/phpstan.neon --port 45829 --identifier pgfusrp9ey --
Restarted (by XDebugHandler) Worker >                    └─php,2540066 -n -c /tmp/YH6yG6 phpstan-src/bin/phpstan worker --configuration /var/www/phpstan.neon --port 45829 --identifier pgfusrp9ey --

@ghost
Copy link
Author

ghost commented Oct 20, 2021

This relates to: phpstan/phpstan-src#726

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant