Issue with user sessions cache after update to v66

Erel

Active Member
Jul 23, 2007
29
2
53
We have upgraded today to cPanel v66.
We are running a Xenforo forum. Strange things happened after the update. Some users were unable to log-in and we couldn't access the admin page.

I first thought that it is related to the new htaccess optimization and disabled it. It didn't help. Eventually I solved the issue by disabling the cacheSessions option in the forum configuration.
Enabling it causes the same issue to appear.

It is most probably related to the latest update. As you are also running Xenforo, maybe you can help with finding the cause of this issue?
 

Erel

Active Member
Jul 23, 2007
29
2
53
Another issue which might be related. File uploads stopped working.
Fixed by setting the value of upload_tmp_dir in php.ini. Not sure why it was commented and what was the previous value but it did work properly in the last 8 years.

I'm pretty sure that I don't understand how to correctly work with the MultiPHP INI editor. The basic tab doesn't include the required option and the editor tab clearly says:

; cPanel-generated php ini directives, do not edit
; Manual editing of this file may result in unexpected behavior.
; To make changes to this file, use the cPanel MultiPHP INI Editor (Home >> Software >> MultiPHP INI Editor)
What is the correct way to change this value?

Overall it was a challenging update for us and the server was not functioning properly for a few hours...
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,909
2,222
463
Hello,

It's possible the issues you faced relate to the following entry in the cPanel 66 Release Notes:

We removed the use of local.ini files in EasyApache 4. WHM's MultiPHP INI Editor interface (Home >> Software >> MultiPHP INI Editor) now saves changes to the php.ini file rather than the local.ini file.
Were you using local.ini files for custom PHP settings with the affected accounts?

Thank you.
 

Erel

Active Member
Jul 23, 2007
29
2
53
I don't think so. Tried looking for a local.ini file and I don't see one.

Anyway, if there is a breaking change then it is worth making a more prominent warning about it (and the updater can actually check whether there is a local.ini file and suggest the nervous administrator what should be done to upgrade successfully).

We are using cPanel to help us administrate our own VPS server. We are not resellers.
We trust you to do your best to keep our servers running.
This is the second update in the last year that breaks our server. The previous one was with the upgrade to EasyApache 4 (the issue was also related to PHP handling).

I'm using cPanel for 8 years now and I don't remember such issues before.
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,909
2,222
463
Hello,

Here's a quote sent by one of our Technical Analysts from a recent support ticket where a similiar concern was brought up:

I do however believe I understand where there may be some additional confusion, and this relates to the 2 changes cPanel version 66 did make to topics related to what's been discussed in this ticket:

1) First change - WHM -> MultiPHP INI Editor now writes to /opt/cpanel/ea-phpXX/root/etc/php.ini instead of ../php.d/local.ini (since local.ini's existence essentially makes user's php.ini files useless under suPHP since local.ini overrides everything within it).

2) Second change - cPanel -> MultiPHP INI Editor now edits .htaccess, .user.ini, OR php.ini, depending on your handler. In cPanel v64, this interface would simultaneously edit php.ini, .htaccess, and .user.ini.
Due to the way local php.ini files work under suPHP (in that they *replace* system-wide php.ini), this file only containing a few directives means all other PHP options will be PHP defaults. This behavior was present in both 64 and 66. I've verified this by installing cPanel 64.0.36 to a test environment and testing further.

The difference between 64 and 66 however is that the local.ini has been transferred over to the system php.ini, leaving the incomplete php.ini files in user directories to result in all their un-speecified directives to be PHP Defaults. I'll agree that this may seem confusing, as the cPanel PHP INI Editor is in the context of making changes to specific directives, when in reality, submitting that form creates a php.ini file which ultimately sets most PHP settings to PHP defaults.

So, in summation, we have below the differences between cPanel 64 and 66:

v64: User's MultiPHP INI Editor in cPanel would write to php.ini, .user.ini, and .htaccess. Under suPHP, the php.ini would override the system-wide php.ini. The presence of a local.ini in /opt/cpanel/ea-phpXX/root/etc/php.d/ would override all the user's php.ini settings, but their customizations were re-implemented with the .user.ini file that was also present.

v66: User's MultiPHP INI Editor in cPanel writes to php.ini for suPHP, .htaccess if they're using DSO, and .user.ini if they're using CGI or PHP-FPM. Due to the lack of local.ini, any settings not specified in their local php.ini would be PHP defaults, leaving ONLY the user's customizations, and no server-wide configurations.
Can you verify if this helps to explain what happened on your system?

Thank you.