PHP suEXEC daemon mode doesn't read in PHP_INI_SCAN_DIR php.ini

[craigles]

Hi Guys,

Just deployed 4.2 onto a server to see if it would fix a previous problem, and also did the whole recompile of php and turned on the PHP suEXEC Daemon mode to give it a good test.

It works fantastic, except for the small fact that it will not read in per user php.ini despite the setting being in the Environment section:

PHP_INI_SCAN_DIR=$VH_ROOT/public_html

Switching straight back from the PHP suEXEC Daemon mode fixes the issue straight away and it starts reading in the per user php.ini's again.

Is this just a bug, or will this be the case and if you use PHP_INI_SCAN_DIR you won't be able to use PHP suEXEC Daemon?

Cheers,
Craig

 

[NiteWave]

are you using cagefs at the same time?

 

[craigles]

No... We are just using normal LVE.
Not CageFS.
Not yet anyway.

 

[NiteWave]

it may still relate to lve.

see if you can disable lve for a while and see if PHP_INI_SCAN_DIR works

 

[craigles]

I turned off LVE in LiteSpeed to see what would happen, but it still doesn't pick up the php.ini at all.

 

[Jesse]

Is there any quick workaround to this issue so we can operate on 4.2, will we have to wait til 4.2.1 or is the new behaviour deemed correct?

 

[NiteWave]

if only a few busy vhosts need separate php.ini, you can define multiple PHPs, (refer http://www.litespeedtech.com/suppor...wiki:multiple_phps_in_control_panel_lsws)echo with fixed php.ini, to work around it.

 

[Jesse]

if only a few busy vhosts need separate php.ini, you can define multiple PHPs, (refer http://www.litespeedtech.com/suppor...wiki:multiple_phps_in_control_panel_lsws)echo with fixed php.ini, to work around it.

Unfortunately it's a shared server which requires our users to define them as required. The other thread indicated there's a bug fix coming soon, so fingers crossed.