I woke up this morning to find that our WHMCS portal for Reclaim Hosting was having some issues. WHMCS is software that enables you to manage the business of cPanel, effectively provisioning, invoicing, billing, renewing, etc. without it people can’t sign-up for new accounts, pay their bill, or access their client area. They can still access their sites through theirdomain.com/cpanel, but they would need to use their SFTP credentials to login there, so it would get bad quickly support-wise. So, when I discovered the 503 Service Unavailable error I knew I needed to fix this immediately. It happened at both a good and bad time. Good because it was late night in North America, so the demand was not peak. Bad because my Reclaim partner Tim Owens was fast asleep 🙂 But, in fact, that might have also been good because I tend to lean on him for this stuff given I’m afraid to mess shit up.
Anyway, the error was there and I went a-Googling, and I found this blog post on Randall Kent’s blog that offers up a resolution. Unfortunately adding
session_name("WHMCS"); to the configuration.php file did not resolve the issue for me. I kept looking online, but got nothing. I then returned to the blog post and worked through the comments, and it turns out this comment by Matt was just just the fix I needed:
This should hopefully fix the issue, keeping the sessions managed only by WHMCS.
1. Create a new directory called ‘session’ and make owner/group writable.
2. open configuration.php and add the following:
session_save_path(__DIR__ . “/session”);
3. Open /.htaccess and add the below for security:
RewriteRule ^session/(.*)$ /index.php
It worked a treat, the one issue I had was the sessions directory was openly writable and in public_html, which was a no-no, so when Tim awoke he recommended I move it out of the public_html directory and change the path, so mine looks like this:
session_save_path('/home/reclaim/session'); ini_set(‘session.gc_probability’, 1);
And it still works! From what I understand it was a cookie conflicting with other PHP applications on the domain. From Randall Kent’s explanation:
WHMCS by default uses the PHPSESSID cookie to track its session. If there are any other PHP applications on the domain which use the same cookie, it can cause a conflict which in WHMCS results in an “Invalid Token” error. It took us a while to track this down as the other apps on the domain gracefully recovered from the shared cookie.
So, the issue is now resolved and WHMCS is working fine. What’s so cool is that I was able to fix a mission critical issue thanks to some one taking some time to share there own issue, and another kind soul chiming in offering further advice and options. This is a brilliant example of blogging and commenting at its best. So, thank you Randall and Matt, your willingness to openly share your work proved invaluable to me this morning.
Thanks a lot this solution works like a charm and it saved me plenty of hours looking for other non working solutions.