By Calvin Crane
nginx log sample line
2017/06/20 15:37:26 [error] 20796#20796: *11706 FastCGI sent in stderr: "PHP message: PHP Warning: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/lib/php/sessions) in /var/www/site.com/html/libraries/joomla/session/handler/native.php on line 194" while reading response header from upstream, client: 94.2.238.187, server: site.com, request: "GET //jreviews/videos?m=6b22D HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.0-fpm.sock:", host: "site.com"
Here is what you see - https://www.evernote.com/l/APHebuV1LQRCDabAqZ6UdEpPcxskMoTzilY
The error is so bad the application fails and this has been linked to a connection problem with the database. Is it possible the connection dies. It is intermittent and quite frequent.
Thanks for any help…this is going to kill my SERPS that aren’t great and one of the reasons for moving to DO.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
I’m not seeing any indication of a database issue, the error seems pretty clear: it’s trying and failing to save php session data at the path specified in the error message. You need to make sure the path in the settings (php settings, not joomla) is correct, and that the filesystem permissions and ownership are also correct.
Hi @landed
The default PHP session.save_path is /var/lib/php/sessions, but if somehow the session cleaner script has never been able to run, then this directory might contain an extreme number of files, which means it cannot create new sessions.
Run this command ls /var/lib/php/sessions | wc -l to get the current count of files.
The issue looks to be more so with PHP than it does MySQL, at least from the error in your post. You can check the MySQL error log by running:
tail -25 /var/log/mysql/error.log
If that doesn’t work, you may need to adjust the path depending on the directory that is used by your version of MySQL.
You should be able to do an ls on the /var/log directory to find the correct one.
ls /var/log
From there, we can see if MySQL is actually crashing and if so, what is being logged. If we find that MySQL is crashing, it’s most likely due to limited RAM, in which case I’d recommend upgrading your Droplet to the next size up. So if this is a 512MB Droplet, upgrade to a 1GB Droplet.
Optimizations can be done on smaller Droplets, though it’s constant and on-going. It’d be far easier to upgrade and add free RAM to what’s available unless your comfortable modifying core configuration and troubleshooting.
…
That said, since this is an [error] and not a [warning], it’s something you need to fix. Generally when PHP can’t write to the sessions directory, it either doesn’t exist or you simply don’t have permission to write to it. That seems to be the case here.
If you run:
ls -al /var/lib/php
the ./sessions directory should be owned by root and have default permissions of drwx-wx-wt. If you seen any variance there, then that may very well be the cause.
In most cases, it’s better to actually write session data to another directory, other than the global, if possible. In some cases this can be configured by the script or application, in others, there are no direct options to do so. You’d have to check and see if Joomla supports this. If it does, you could simply create a new directory below your public directory and call it session and change to use that directory. That way you’re in full control over the directory and how it’s handled.
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
Full documentation for every DigitalOcean product.
The Wave has everything you need to know about building a business, from raising funding to marketing your product.
Stay up to date by signing up for DigitalOcean’s Infrastructure as a Newsletter.
New accounts only. By submitting your email you agree to our Privacy Policy
Scale up as you grow — whether you're running one virtual machine or ten thousand.
Sign up and get $200 in credit for your first 60 days with DigitalOcean.*
*This promotional offer applies to new accounts only.