wallitin Posted February 10, 2015 Share Posted February 10, 2015 I get an intermittent 'unable to access /var/lib/php5 - permission denied'. It's genererated randomly when session_start() is called from classes/session.class.php line 600. I'm running Ubuntu 14.04. The directory /var/lib/php5 has permissions drwx-wx-wt root root. Apache's group is www-data. From a post on: http://stackoverflow.com/questions/2904862/issues-with-php-5-3-and-sessions-folder "The reason it happens sporadically is that the error occurs when the session garbage collector is run, which I think by default has a 1% chance of running per session initialization. Essentially, the garbage collection is set up to be done by cron jobs on some systems (i.e. Ubuntu/Debian). Some php ini executables like php-cli also try to do garbage collection and that results in the error you got." Since garbage collection is already being handled by a cron job on Ubuntu, the solution is to set session.gc_probability to 0 in /etc/php5/apacha2/php.ini and restart apache2. But ... In classes/session.class.php on line 79 session.gc_probability is set to 15 which would defeat setting it to 0 in /etc/php5/apache2/php.ini. Changing the permissions on the /var/lib/php5 would be a security risk. What is the solution? Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted February 10, 2015 Share Posted February 10, 2015 I see the issue with CC setting the value. You could disable ini_sets at PHP run time? You can do this in the php.ini file in the section "disable_functions". http://php.net/manual/en/ini.core.php#ini.disable-functions Quote Link to comment Share on other sites More sharing options...
bsmither Posted February 10, 2015 Share Posted February 10, 2015 Huh? Disable ini_set()? Why would this be a good idea? And if you have access to php.ini, move all those ini_set() arguments to the php.ini file to begin with. Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted February 10, 2015 Share Posted February 10, 2015 I don't see why not. So long as the default ones are ok. Many web hosting providers seem to ignore the PHP ini_set function from my experience. What host wants to allow their user to max out the PHP memory limit etc!!?? This can be of detriment to other account holders. A $5 a month account holder shouldn't be able to take 16GB off the server. Quote Link to comment Share on other sites More sharing options...
bsmither Posted February 10, 2015 Share Posted February 10, 2015 ini_set('session.name', 'HTDOCSCC600B4'); // Customise the session name here, if you feel PHPSESSID is too insecure Or collides with other applications you have on your site. Quote Link to comment Share on other sites More sharing options...
wallitin Posted February 10, 2015 Author Share Posted February 10, 2015 It would be nice to have a list of php.ini settings for cubecart. I could change the settings in /etc/php5/apache2/php.ini and disable ini_set(); I could change session.gc_probability depending on the server I'm hosting my web site on. Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted February 10, 2015 Share Posted February 10, 2015 The default PHP settings should be fine to be honest so long as a typical PHP build has been made with cURL, GD etc.. Quote Link to comment Share on other sites More sharing options...
wallitin Posted February 10, 2015 Author Share Posted February 10, 2015 In ini.inc.php line 171: // Include a custom ini file, if it exists if (file_exists(CC_ROOT_DIR.'/ini-custom.inc.php')) { include CC_ROOT_DIR.'/ini-custom.inc.php'; } This is executed before classes/session.class.php. Would it help to have something similar in session.class.php? session.gc_probability could be set back to 0; Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted February 11, 2015 Share Posted February 11, 2015 I would suggest the best cause of action is to fix the issue at server level. You simply shouldn't get this error and the article you saw on StackOverflow merely seems like a work around. Maybe you need some server management services from an experienced linux server administrator? Quote Link to comment Share on other sites More sharing options...
wallitin Posted February 11, 2015 Author Share Posted February 11, 2015 I will defer to your expertise and only use cubecart with professional server management services. Good to know. Thank you for your advice. Quote Link to comment Share on other sites More sharing options...
Al Brookbanks Posted February 11, 2015 Share Posted February 11, 2015 Any shared web hosting should work fine. Are you an experienced server administrator? If so I apologise if you took offence by my last comment. I'm unable to tell by your last response. The issue you have is certainly uncommon and I don't recall seeing it before at all. In the mean time I would suggest editing the line of code in the session class file. You'll need to remember to do that with every upgrade however. Quote Link to comment Share on other sites More sharing options...
havenswift-hosting Posted February 11, 2015 Share Posted February 11, 2015 I don't see why not. So long as the default ones are ok. Many web hosting providers seem to ignore the PHP ini_set function from my experience. What host wants to allow their user to max out the PHP memory limit etc!!?? This can be of detriment to other account holders. A $5 a month account holder shouldn't be able to take 16GB off the server. Any hosting company that cares about the security of client hosting accounts (as opposed to just the security of the server) will disallow the use of local php.ini files - unfortunately cheap hosting companies often dont. Doing this also has the effect of stopping individual accounts modifying settings like this and causing issues The default PHP settings should be fine to be honest so long as a typical PHP build has been made with cURL, GD etc..I completely agree that a standard LAMP installed server should be able to run CubeCart with no issues at all - whether it will run it well and fast is then down to how well the company configures Apache, MySQL and a whole host of other things. Most companies will configure to get the most accounts on a single server and will make it a generalised setup rather than configuring specifically for E-Commerce / high MySQL usage sites. You always get what you pay for with hosting - cheap is cheap for a reason !Ian Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.