Plesk 11.5 multiple php versions: php.ini files do not load

[jazz090]

I was able to configure my Plesk to read the latest version of PHP from source. However, when I edit the php.ini file associated with the particular installation (the one I assigned to the Plesk php_handler), the modifications are not loaded at runtime.

For example, changing memory_limit from 128M to 64M, still shows 128M in runtime, despite of a reboot and running the --reread flag on the Plesk php_handler

memory_limit = 64M

<?php
echo ini_get("memory_limit")."<br />"; //comes back with 128M (should now be 64M)
?>

 

[abdi]

Just run:

<?php phpinfo(); ?>

That should give you which and the location of the php.ini file being used at run-time! Then you can start from there ...

 

[jazz090]

OK just ran phpinfo(). It seems the configuration file loaded is located at /var/www/vhosts/system/mywebsite.TLD/etc/php.ini as opposed to /usr/local/php-5.5.3/etc/php.ini which I set during PHP source configuration and the one I have been editing. I tried editing the former but this was writer in the file:

; DO NOT MODIFY THIS FILE BECAUSE IT WAS GENERATED AUTOMATICALLY,
; SO ALL YOUR CHANGES WILL BE LOST THE NEXT TIME THE FILE IS GENERATED.

I can't find any php.ini files located in the file container of my domain either.

Regardless of which php.ini file I edit, I am editing the master file so it should load correctly.

I have followed these steps for setting up my custom PHP: http://download1.parallels.com/Ples...inistrator-guide/index.htm?fileName=72042.htm

But according to this (http://kb.parallels.com/en/114753) which is slightly older, some kind of a wrapper must be created with Apache?

 

[abdi]

Am not sure why I can't see your response and yet got an email notification of your reply!
However, Just delete the file

/var/www/vhosts/system/mywebsite.TLD/etc/php.ini

and the main one for the server will take effect immediately!

 

[jazz090]

[strikethrough]I removed /var/www/vhosts/system/mywebsite.TLD/etc/php.ini and as you said, the file generated itself automatically. However, the variables are still not being imported neither in phpinfo() or the newly generated php.ini file.[/strikethrough]

 

[Nikolay.]

It's a bug. Don't sweat it. Just set memory_limit (and other differing options) in custom PHP settings for the domain until it is fixed.

You may want to post a bug report according to a template that's used on this forum so the problem gets noticed.

 

[jazz090]

Scratch that. It worked!!!!!!

However, this time I just deleted the file and refreshed my php page without rebooting the server or doing httpd reconfigure all.

Thank you so much for your help.

Do you know if there are any tutorials on how to set individual php.ini file for each domain without it getting over written?

 

[jazz090]

Looking at this in more depth, this does indeed seem to be a bug. When hosting settings for a domain is changed (the same place where the PHP version is assigned in Plesk, along with the ability to enable SSL, CGI, Perl, etcc), this file gets written: /var/www/vhosts/system/mywebsite.TLD/etc/php.ini. The bug is that this file does not follow the template set forth in the master php.ini file in /usr/local/php-5.5.3/etc/php.ini. It's based on some other template. Every time I make a change in hosting settings via Plesk, this file gets written and over-writes the master at run-time, without following master ini rules. Consequently, updating hosting settings can result in code malfunction. In my case, I just edited my php.ini file to point to my mysql.sock file to allow UNIX socket connections instead of TCP/IP. When I changed the hosting setting (why my first attempt above was unsuccessful), the new file that was generated was not following the master template so the location for mysql.sock was empty and my code failed. Removing /var/www/vhosts/system/mywebsite.TLD/etc/php.ini does the trick. However, unlike as suggested by abdi, the file is not recreated. Only until the hosting settings are configured through Plesk again that this file is generated. I am considering closing all file permissions (chmod 444) in /var/www/vhosts/system/mywebsite.TLD/etc/ as a temp workaround for the bug, but I don't know if that is a good idea. There aren't any other files in this dir.

Nevertheless, this file would be very useful for assigning php.ini rules as per domain. However, the file is not stable and is hard to guess what template it follows.

 

[Nikolay.]

I am considering closing all file permissions (chmod 444) in /var/www/vhosts/system/mywebsite.TLD/etc/ as a temp workaround for the bug, but I don't know if that is a good idea.

Quite a bad idea. Have you even read my post above? Custom PHP settings can be tuned via Panel GUI. Please address documentation for details.

Nevertheless, this file would be very useful for assigning php.ini rules as per domain. However, the file is not stable and is hard to guess what template it follows.

Incidentally, that's its purpose. Due to the bug server-wide php.ini for the default PHP is used.

 

[jazz090]

I did read your post, not sure what you meant by 'template'. Why is that a bad idea? Setting custom PHP settings via GUI instigates the whole issue. As long as those are not changed via GUI, then the file isn't created. Because the whole thing is temperamental, my initial suggestion is to turn off permissions for that particular directory. I have no idea if any other Plesk code, which when ran through GUI (or otherwise), creates that file. You don't even need to change PHP settings in hosting settings. If I turn off SSL on my site, for example, my code will break because that particular page in Plesk triggers the file creation step process. I cant risk my code breaking whenever I change something in Plesk.

 

[abdi]

As long as you have NOT set any custom php settings for the respective domain name through Plesk -> websites -> PHP Settings, then the custom php.ini will NOT exist. So if you want to get rid of it totally, then just reset the php settings back to the default in your plesk panel.

 

[jazz090]

Unfortunately that is not correct. In Websites & Domains > Hosting Settings, any changes made here, regardless of their association with PHP will create the file. For instance, I just turned off my SSL support (just unchecked SSL support and hit OK) and as a result my code no longer functions (because the master php.ini file had defined the mysql.sock my code uses to establish connection with database).

I am curious about other scripts that may create this file. Clearly, its not just PHP Settings page. Although both are kind of in a way related to changing PHP settings as hosting settings allows changing the PHP version and presumably when the OK button is pressed, the PHP version is assigned again, regardless of whether it was actually changed in GUI. This explains why disabling SSL support creates the php.ini file.

 

[abdi]

It re-creates it in your situation simply because you had already set custom php settings prior to that! If you had not, just changing anything at Websites & Domains > Hosting Settings does not create php.ini file ...(I have tested it and the assumption is true!)

 

[jazz090]

I have only changed PHP settings on the native version on a different domain. For the custom version, all the PHP settings are on their default and I when I was trying to figure out why the master file would not load, I added and removed the PHP handler from Plesk a few times. I haven't made any changes to the custom version. Would I have to go back and set everything to default on the native?

 

[abdi]

Yes, that is true! PHP handler trigger's it's creation! Am not sure there's anyway to reverse the process so that it doesn't get re-created all the time!

 

[Nikolay.]

Ugh.

Don't sweat it. Just set memory_limit (and other differing options) in custom PHP settings for the domain until it is fixed.

Or just hardlink your php.ini to /var/www/vhosts/system/<domain.tld>/conf/php.ini and regenerate etc/php.ini any way you see fit. Or just paste php.ini to custom PHP directives window in UI. So many options to workaround the bug, yet they go by unnoticed for some reason.


Regarding changing permissions: try it if you want to. But most likely you'll get more problems eventually. And not immediately either (e.g., on upgrade), so you wouldn't be able to connect the cause to the issue.

 

[abdi]

I am considering closing all file permissions (chmod 444) in /var/www/vhosts/system/mywebsite.TLD/etc/ as a temp workaround for the bug, but I don't know if that is a good idea

A better work around would be empty your /var/www/vhosts/system/mywebsite.TLD/etc/php.ini (ie, it's there but empty!)
Then lock it against any system changes with

chattr +i /var/www/vhosts/system/mywebsite.TLD/etc/php.ini

I havent tested the above, though theoretically it should work!

 

[Nikolay.]

Then lock it against any system changes with

chattr +i /var/www/vhosts/system/mywebsite.TLD/etc/php.ini

I havent tested the above, though theoretically it should work!

NEVER EVER DO SUCH STUFF! This is worse than setting restrictive permissions. Also with empty php.ini this will not achieve what jazz090 is looking for.

 

[abdi]

NEVER EVER DO SUCH STUFF! This is worse than setting restrictive permissions. Also with empty php.ini this will not achieve what jazz090 is looking for.

Explain why you think it's worse?

About an empty php.ini:
theoretically, all custom variables in this file will over-ride the php.ini primary / master variables. So if the custom php.ini file is empty this also means there will be nothing to over-ride that way all that there's in the master php.ini should take effect ...

 

[jazz090]

About an empty php.ini: theoretically, all custom variables in this file will over-ride the php.ini primary / master variables. So if the custom php.ini file is empty this also means there will be nothing to over-ride that way all that there's in the master php.ini should take effect ...

Just tried this hoping for a neat solution. I was hoping I could place only the variables I wanted for a particular domain to use in /var/www/vhosts/system/mywebsite.TLD/etc/php.ini. That didn't work. If the php.ini is empty, that doesn't get superseded by the master either. The file must not exist as Nikolay says.