How to override / set php options for Drush 9+?

[frederickjh]

With the move to Drupal 8.4 I switched one of my sites to a site installed Drush 9. I also installed the Drush launcher.

Drush Launcher Version: 0.5.0
Drush Commandline Tool 9.0.0-rc1

I have the following environmental variables related to Drush set:

DRUSH_INI="/home/username/.drush/drush.ini"
DRUSH_LAUNCHER_FALLBACK="/home/username/.composer/vendor/bin/drush"
DRUSH_PHP="/opt/cpanel/ea-php71/root/usr/bin/php"

This is on a server where the php.ini for the cli sets memory_limit=32M. With Drush 8 globally installed I could use ~/.drush/drush.ini to set memory_limit=512M.

I did see in issue #2934 that the drush.ini file is ignored and that that the drush launcher does not handle drush.ini either.

I have tried unsuccessfully to run Drush 9 and increase the memory limit. Here is what I have tried using the updb to test the memory_limit=32M:

$ php -d memory_limit=512M ../vendor/bin/drush --php-options=memory_limit=512M
Drush Commandline Tool 9.0.0-rc1
. . .

It appears that --php-options is not a valid option with Drush 9 as it spits out the default help text after the above console output.

$ php -c ~/.drush/drush.ini ../vendor/bin/drush -c ~/.drush/drush.ini updb
 [error]  Drush command terminated abnormally due to an unrecoverable error.
Error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 8192 bytes) in /home/meosch/l2m.ch/releases/20171229-022429/docroot/core/lib/Drupal/Core/Extension/InfoParserDynamic.php, line 22 
 [error]  The external command could not be executed due to an application error.

So setting the PHP options in a file does not seem to work either. I made a copy of the default php.ini and then increased memory_limit=512M.

---

So, is there a way to set php options for Drush 9? And is is also possible to use the Drush launcher with this too?

[frederickjh]

Interestingly running:

php -c ~/.drush/drush.ini ../vendor/bin/drush -c ~/.drush/drush.ini php:cli

Then running: phpinfo() I see in the php info:

memory_limit => 512M => 512M

So, the php cli is seeing the php option but drush updb does not.

[weitzman]

Drush 9 is now out of the business of setting up your PHP environment. It got too complex to maintain this.

Drush does create subprocesses for some commands (sql-sync, updb, config-pull, ...). Those subprocesses probably dont see the -c option so the subprocess gets memory starved. Thats my guess.

That doesn't really answer your question. For right now, Drush9 is declaring the question "out of scope". At minimum, I'd like to add some docs to help people who are using a constrained php environment like you are.

[frederickjh]

Thanks @weitzman for the reply. I tried everything I could think of my greatest hope was a bash alias for php that added the php.ini via the -c option but as you said it seems the sub processes do not see it.

I was able to get the memory_limit on the VPS PHP configuration raise to an acceptable level so I am back in business. However I do hope that a solution to this for others can be found.

[weitzman]

Update: An alternative PHP_INI_SCAN_DIR approach is documented below

I think the best way to do this is to insure that the PHPRC environment variable is set to the directory containing the desired php.ini. Subprocesses get the same environment so the change persists there.

You can set the variable just for one request. See PHP Config line below:

~/reps/mass (develop *=) $ PHPRC=/tmp drush st
 Drupal version : 8.4.5                                                                  
 PHP config     : /tmp/php.ini                                                 
 PHP OS         : Darwin                                                       
 Drush script   : /Users/moshe.weitzman/bin/drush                              
 Drush version  : 9.2.1                                                        

[weitzman]

now documented in install docs

[frederickjh]

@weitzman This works on linux in a normal bash shell but not in a Cpanel bash jailedshell.

To test on both servers I created a /tmp/php.ini file that sets the memory_limit = 128M.

Normal Linux User:

$ PHPRC=/tmp env | grep PHPRC
PHPRC=/tmp
$ PHPRC=/tmp drush st
 Drupal version : 8.4.4                                                      
 Site URI       : default                                                    
 DB driver      : mysql                                                      
 DB hostname    : db                                                         
 DB port        : 3306                                                       
 DB username    : user                                                       
 DB name        : default                                                    
 PHP binary     : /usr/bin/php7.1                                            
 PHP config     : /tmp/php.ini                                               
 PHP OS         : Linux                                                      
 Drush script   : /home/user/docker/l2mch/vendor/bin/drush             
 Drush version  : 9.1.0                                                      
 Drush temp     : /tmp                                                       
 Drush configs  : /home/user/docker/l2mch/vendor/drush/drush/drush.yml 
                  /home/user/docker/l2mch/drush/drush.yml              
 Drupal root    : /home/user/docker/l2mch/docroot                      
 Site path      : sites/default                                              
$ drush --version
Drush Launcher Version: 0.5.1
Drush Commandline Tool 9.1.0
$

Cpanel Jailed shell user

$ PHPRC=/tmp env|grep PHPRC
PHPRC=/tmp
$ PHPRC=/tmp drush st
$

The drush st command returned no output in the shell. I then tried the direct path to Drush 9 in the Drupal 8 project.

$ PHPRC=/tmp vendor/bin/drush st

Fatal error: Uncaught Error: Call to undefined function Drush\Preflight\ctype_alpha() in /home/user/example.com/releases/20180205-090119-live-0.2.0/vendor/drush/drush/src/Preflight/ArgsRemapper.php:49
Stack trace:
#0 /home/user/example.com/releases/20180205-090119-live-0.2.0/vendor/drush/drush/src/Preflight/ArgsRemapper.php(32): Drush\Preflight\ArgsRemapper->checkRemap('st', false)
#1 /home/user/example.com/releases/20180205-090119-live-0.2.0/vendor/drush/drush/src/Preflight/ArgsPreprocessor.php(55): Drush\Preflight\ArgsRemapper->remap(Array)
#2 /home/user/example.com/releases/20180205-090119-live-0.2.0/vendor/drush/drush/src/Preflight/Preflight.php(163): Drush\Preflight\ArgsPreprocessor->parse(Array, Object(Drush\Preflight\PreflightArgs))
#3 /home/user/example.com/releases/20180205-090119-live-0.2.0/vendor/drush/drush/src/Preflight/Preflight.php(229): Drush\Preflight\Preflight->preflightArgs(Array)
#4 /home/user/example.com/releases/20180205-090119-live-0.2.0/vendor/drush/drush/src/Runtime/Runtime.php(58): Drush\Preflight\Preflight->prefl in /home/user/example.com/releases/20180205-090119-live-0.2.0/vendor/drush/drush/src/Preflight/ArgsRemapper.php on line 49
$ drush --version
Drush Launcher Version: 0.5.0
Drush Commandline Tool 9.0.0-rc1
$

Let me know if there is any more information that I can supply or test I can run to help fix this.

[frederickjh]

Do you think the version of the Drush command line tool has anything to do with it? Just saw that one is an RC and the other is a stable release version.

[weitzman]

Seems like the original question has now been answered.

could you edit this line and add a `\ before ctype_alpha. that may fix it. I'm not clear when that's needed since php has a fallback policy.

[weitzman]

And yeah, 9.0.0-rc1 is quite old. Tha could be contributing to the problem. Hard to say.

[frederickjh]

@weitzman I made the modification that you suggested above adding / before ctype_alpha, so that the line looks like this:

if (!$sawCommand && /ctype_alpha($arg[0])) {

I also updated Drush before:

Drush Launcher Version: 0.5.0
Drush Commandline Tool 9.1.0

However still got no ouput when I run PHPRC=/tmp drush st.

[weitzman]

slash needs to go in other direction - \

[frederickjh]

Sorry, I tried it again with the line if (!$sawCommand && \ctype_alpha($arg[0])) { and still no output.

[weitzman]

Sounds like your PHP does not have the ctype extension. Thats quite rare.

[bioshazard]

I landed here searching for how to deal with this in Drush 9 and settled on this so I didn't have to maintain a physical file for my override:

php -c <(echo "sendmail_path=$(which true)")  /.../vendor/drush/drush/drush.php ev 'return ini_get("sendmail_path")'

[dabley]

Note that if you simply want to modify a few of the php.ini parameters, then rather than using the PHPRC environment variable to specify a completely new php.ini file, there's a simple way to specify an additional '.ini' file which contains just your customisations.

After php has loaded the php.ini file located in the directory indicated by the PHPRC
environment variable (or indicated by other means), it then scans for other .ini files located in one or more other directories. You can easily get php to search an extra directory of your choice, by setting the PHP_INI_SCAN_DIR environment variable.

For example, create a directory /home/myname/mydrush, and in this put a file named drush.ini, containing the custom initialisation commands you require. Then you can call drush with:

$ PHP_INI_SCAN_DIR=:/home/myname/mydrush drush <drush command>

The colon at the front of the assignment causes the directory you specify to be added to the end of the list of additional directories that php searches looking for .ini files when it starts up. (In Ubuntu 18.04, for example, php 7.3 will scan for additional .ini files in the directory /etc/php/7.3/cli/conf.d)

You can get a confirmation of exactly which .ini files php is loading using a command such as:

$ PHP_INI_SCAN_DIR=:/home/myname/mydrush php --ini

Note that with php 7.3.16, this command will show:

Scan for additional .ini files in: :/home/myname/mydrush

This is misleading - it doesn't list the names of the other "additional" directories that are scanned prior to your custom one. But you can easily reassure yourself that they are in fact being scanned, because the command goes on to list "Additional .ini files parsed: ", and there you'll see the complete list of .ini files loaded.

For more on PHP_INI_SCAN_DIR, see https://www.php.net/manual/en/configuration.file.php

[weitzman]

Great tip! I added a link to it from the comment above thats linked in the install docs.

[StudioVDS]

I can't get this to work, hope you can help me with this:
First I do this: PHPRC=/tmp env | grep PHPRC
Getting this: PHPRC=/home/domain/tmp as output

Then when I try drush st I get this:
[preflight] The following restricted PHP modes have non-empty values: {disable_functions}. This configuration is incompatible with drush. {Please check your configuration settings in /home/domain/tmp/php.ini or in your drush.ini file; see examples/example.drush.ini for details.}

So it looks like it is looking at the right php.ini file but still I get this message even though have removed all disable_functions from this specific file. What am I doing wrong?

[dabley]

First I do this: PHPRC=/tmp env | grep PHPRC

This only causes the value of PHPRC to be set for the single command "env". If you want the setting of PHPRC to apply when you call drush, you either need to do the setting on the same line where you invoke drush, e.g.

$ PHPRC=/tmp drush [drush command]

Or, you can make the setting persist in your current shell environment by doing:

$ export PHPRC=/tmp
$ drush [drush command]

[StudioVDS]

Thanks, but unfortunately this doesn't work as expected:
$ PHPRC=~/tmp drush --version

Outputs:

 [preflight] The following restricted PHP modes have non-empty values: {disable_functions}. This configuration is incompatible with drush.  {Please check your configuration settings in /home/domain/tmp/php.ini or in your drush.ini file; see examples/example.drush.ini for details.}

So it does find my custom php.ini file but still doesn't work. And when removing the Disable Functions via Direct Admin (just for testing) it does work...?

[dabley]

Hi StudioVDS,
In the file /home/domain/tmp/php.ini, what do you have for the setting of disable_functions? And can you also try:
$ PHPRC=/tmp php --ini
and check to see what additional ini files are being loaded. Maybe one of those is changing the setting of disable_functions?
If you are only wanting to change the value of disable_functions, you may find it easier to just load an additional ini file using the PHP_INI_SCAN_DIR variable, as I explained in an earlier comment: #3294 (comment).

[StudioVDS]

Hi,

I'm using the drush.ini file I used for Drush 7. You can see it here.

When I use php --ini I get this:

Configuration File (php.ini) Path: /opt/alt/php73/etc
Loaded Configuration File:         /home/domain/tmp/php.ini
Scan for additional .ini files in: /opt/alt/php73/link/conf
Additional .ini files parsed:      /opt/alt/php73/link/conf/alt_php.ini

But still I get this message:
[preflight] The following restricted PHP modes have non-empty values: {disable_functions}. This configuration is incompatible with drush. {Please check your configuration settings in /home/domain/tmp/php.ini or in your drush.ini file; see examples/example.drush.ini for details.}

About the PHP_INI_SCAN_DIR option. This does work. A question about this. I added:
export PHP_INI_SCAN_DIR=:~/tmp to my .bash_profile file. Now the custom php.ini file is only loaded when using the terminal, it's not overwriting the regular php.ini file the server is using?

[dabley]

Hi StudioVDS,
I'm guessing that before calling php --ini you had set the environment variable PHPRC to /tmp, and similarly before you invoked drush, and that the ini file you cited is the one that's located in /home/domain/tmp/php.ini?
The output from php --ini shows that the file /opt/alt/php73/link/conf/alt_php.ini is loaded after your custom ini file, so there's a possibility that this might be altering the value of disable_functions, and setting it to something that drush doesn't like. You might like to check this.
If you use PHP_INI_SCAN_DIR to add your custom file to the end of the list of ini files that are loaded, then you can avoid this risk.

I'm pretty confident that your .bash_profile file is not being loaded by your webserver, but if you want to be sure, just make a short php script that runs phpinfo(); put it in your docroot, and load it through a web browser. This will show you what ini files are loaded. (Delete the script when you're done - it can be a security risk otherwise.)