So I have a website running joomla, and I tried setting the session handler to redis from CMS admin dashboard. I am getting the following error on homepage and every other page of the website I visit.
Error: Failed to start application: Connection closed
Fatal error: Uncaught RedisException: Connection closed in /var/www/xxxx/libraries/joomla/session/handler/native.php:194 Stack trace: #0 /var/www/xxxx/libraries/joomla/session/handler/native.php(194): session_write_close() #1 [internal function]: JSessionHandlerNative->save() #2 {main} thrown in /var/www/clients/client3/web9/web/libraries/joomla/session/handler/native.php on line 194
My server is configured with php-fpm as default, Now the interesting thing is that, if I change the php-wrapper/module to run with Fast-CGI (from my server control panel) everything works perfect.
Btw, I am using PHP-Redis as the client library, on Ubuntu, and ISPConfig as my control panel for a LAMP setup.
OK, So after a lot of hair pulling, and thank God i've got these amazing goog-foo skills, here is the solution.
If you are using ISPConfig 3, and experiencing the same problem, Just do as I say below, don't ask why, no time to explain.
On line 39 of the file /usr/local/ispconfig/server/conf/php_fpm_pool.conf.master you'll find the following template tags.
<tmpl_if name='custom_session_save_path' op='!=' value='y'>
php_admin_value[session.save_path] = <tmpl_var name='document_root'>/tmp
</tmpl_if>
Just delete it! Yeah you read that right, you gotta delete those lines man. And after saving the changes from the admin panel, goto
ISPConfig Admin Panel > Sites > Domain > PHP
and toggle that option to disabled and let it update on the server and then set that option back to PHP-FPM. And....aahhh the glorious redis with the totally fab php-fpm.
Ok, you can ask why, was kidding earlier:D
As per this thread what was happening was that joomla(like many other CMSs) tries to change the session.save_path to redis during runtime as per the settings made in admin panel of the CMS, but the "fpm-pool-template" which is shipped with ISPConfig 3 was trying to make that value editable from the Server Control panel, in the process it was making it impossible for php to change/overwrite that value during runtime.
As described here.
...Any directive type set with php_admin_value can not be overridden by .htaccess or ini_set().
Now, Is it safe? ..to remove these tags with the directives.
Its perfectly safe to remove the aforementioned lines, and those were written for the users to further modify to their needs as discussed here. Furthermore the function used was a bit too strict (IMHO) and the same effect could have been achieved using the lesser authoritarian php_value.