PHP limits reverting to defaults - again
-
I don't see other reports of this internally and if it were happening widespread there would typically be a number of tickets being open for this and a case. Furthermore, I am unable to replicate this when setting the memory limit using the API or the interface. Because of that, I believe this is something that should be investigated further. I'd suggest you open a ticket with a server that has experienced this as an example. 0 -
I might agree with you if this wasn't happening on new servers that have only just had the OS and cpanel installed. These are new setups. Also - it doesn't happen immediately. Seems to be something in the cpanel update process causing this randomly. To properly test it you will need to set up a server, configure PHP using the API only and leave it a while. It might have been the update to cpanel 90 that caused this. Regardless, it's most definitely not going to be something specific to our environment since there is nothing different here than anywhere else. We set up Centos 7 - install cpanel with a Cloudlinux license and run EA4 and we set the PHP ini settings as mentioned along with the default version and handler via the API. On older and newer servers, we've seen the limits get reset quite a few times. As mentioned, previously we were copying the ini files and the changes were getting reset. We've had more luck with the API - but still the memory limit is getting reset. It's obvious that a process in the cpanel update / environment is causing this and I think it would be more practical if you were to ask your developers exactly what could cause this issue to happen - under what circumstances? I'm wiling to accept that the issue might be caused by something happening inside Cloudlinux - since they do seem to mess with the EA4 / PHP setup somewhat - but we don't have their selector running or any alt-php packages. Its all EA4. I think it's important to put this stuff in the forums because other people with the same issue might contribute. 0 -
Just to add... We set up two new servers this morning and within an hour of setting the PHP limits via the API, the memory_limit directive had reverted to 128M The only significant process that ran on the server after the API commands was cagefsctl --force-update so I wonder if CageFS has something to do with this issue. 0 -
I'm wiling to accept that the issue might be caused by something happening inside Cloudlinux - since they do seem to mess with the EA4 / PHP setup somewhat - but we don't have their selector running or any alt-php packages. Its all EA4.
I'm also not using CloudLinux on my test server, so I'll set that up and see what happens.I think it's important to put this stuff in the forums because other people with the same issue might contribute.
I agree it is useful in the forums, I apologize if my suggestion made it seem as as though it wasn't it's just that sometimes to find the cause of an issue it's best to have access to the server it's occurring on, especially when I don't have any other reports of this behavior and I can't replicate it. I created a CloudLinux test server and ran the following for PHP 7.3:[ root@CloudlinuxTest [] ~]# /usr/local/cpanel/bin/whmapi1 php_ini_set_directives directive-1=allow_url_fopen%3AOn directive-2=max_execution_time%3A360 directive-3=max_input_time%3A360 directive-4=max_input_vars%3A5000 directive-5=memory_limit%3A512M directive-6=post_max_size%3A512M directive-7=upload_max_filesize%3A512M directive-8=date.timezone%3A%22Europe%2FLondon%22 version=ea-php73 --- data: {} metadata: command: php_ini_set_directives reason: OK result: 1 version: 1
Then checked it:[ root@CloudLinuxTest [] ~]# /usr/local/cpanel/bin/whmapi1 php_ini_get_directives version=ea-php73 |egrep 'key:|value:'| grep -v default_value key: allow_url_fopen value: 'On' key: allow_url_include value: 'Off' key: display_errors value: 'Off' key: enable_dl value: 'Off' key: file_uploads value: 'On' key: max_execution_time value: 360 key: max_input_time value: 360 key: max_input_vars value: 5000 key: memory_limit value: 512M key: post_max_size value: 512M key: session.gc_maxlifetime value: 1440 key: session.save_path value: /var/cpanel/php/sessions/ea-php73 key: upload_max_filesize value: 512M key: zlib.output_compression value: 'Off'
And then ran the update manually (no force)/scripts/upcp
Then let it sit overnight and run the maintenance update and checked again with no changes:[ root@CloudLinuxTest [] ~]# /usr/local/cpanel/bin/whmapi1 php_ini_get_directives version=ea-php73 |egrep 'key:|value:'| grep -v default_value key: allow_url_fopen value: 'On' key: allow_url_include value: 'Off' key: display_errors value: 'Off' key: enable_dl value: 'Off' key: file_uploads value: 'On' key: max_execution_time value: 360 key: max_input_time value: 360 key: max_input_vars value: 5000 key: memory_limit value: 512M key: post_max_size value: 512M key: session.gc_maxlifetime value: 1440 key: session.save_path value: /var/cpanel/php/sessions/ea-php73 key: upload_max_filesize value: 512M key: zlib.output_compression value: 'Off'
0 -
I'll update cagefs as well and see what I get 0 -
I'm not seeing a difference here after updating CageFS but it could still be responsible for the issue you're having. [ root@CloudLinuxTest [] ~]# /usr/local/cpanel/bin/whmapi1 php_ini_get_directives version=ea-php73 |egrep 'key:|value:'| grep -v default_value key: allow_url_fopen value: 'On' key: allow_url_include value: 'Off' key: display_errors value: 'Off' key: enable_dl value: 'Off' key: file_uploads value: 'On' key: max_execution_time value: 360 key: max_input_time value: 360 key: max_input_vars value: 5000 key: memory_limit value: 512M key: post_max_size value: 512M key: session.gc_maxlifetime value: 1440 key: session.save_path value: /var/cpanel/php/sessions/ea-php73 key: upload_max_filesize value: 512M key: zlib.output_compression value: 'Off'
Do you have any customizations made to the installations you use? I'm going to leave the CL test server up for the weekend to see if I can replicate anything with the php.ini file changing as well.0
Please sign in to leave a comment.
Comments
6 comments