phpMyAdmin - Error session_write_close()

Hi,

I use don't know what happened but suddenly I can't login to phpMyAdmin. I didn't change any server configuration.
I can't also login to my Wordpress site - after giving right credentials it redirects back to login page after page reload.

When I open phpMyAdmin site error occurs:
Error during session start; please check your PHP and/or webserver log file and configure your PHP installation properly. Also ensure that cookies are enabled in your browser.

session_write_close(): write failed: No space left on device (28)

session_write_close(): Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php/sessions)

I tried to set chmod 777 for /var/lib/php/sessions, cleared browser cache and removed session files from the srever - but nothing helps.

Does anyone know what might be the problem and how to solve it?

Using ISPConfig 3 on Ubuntu 18.04 with PHP 7.2.
Followed installation guide https://www.howtoforge.com/tutorial...l-pureftpd-bind-postfix-doveot-and-ispconfig/

 

Hi,
Thanks for reply.

Looks like I'm ok with disk space
Filesystem Size Used Avail Use% Mounted on
udev 2.0G 0 2.0G 0% /dev
tmpfs 395M 640K 394M 1% /run
/dev/vda2 40G 24G 14G 63% /
tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
tmpfs 395M 0 395M 0% /run/user/0

 

Is quota used and that user is over quota?

 

I guess so, I did "11. Install PureFTPd and Quota" point from installation quide.
root@server:~# quotacheck -a
quotacheck: Quota for users is enabled on mountpoint / so quotacheck might damage the file.
Please turn quotas off or use -f to force checking.

I'm kind a new here so not sure if used proper command

 

Anyone can help?

 

couple of long shot possibilities..

1. I see you've listed df -h output, was that everything? did you have other drives/partitions mounted?
I've seen where eg /var/www already contains files, and a drive is then mounted to /var/www, the original files are still taking up space, but not being counted, and of course, are not accessible to delete. you could try unmounting everything else and then checking disk space.

2. I assume you're trying to access phpMyAdmin by going to <wordpresssiteurl>/phpMyAdmin rather than <servername/ip>/phpMyAdmin. since you are also having issues logging into wordpress. maybe you're using a security plugin like wordfence that is interfering with your access. you could try deleting any such plugin from the wp-content/plugins folders.

other than that, Talemans suggestion of quota limits seems like the most likely cause. try running quotaoff and then try logging into phpMyAdmin or wordpress without restarting the server.

 

Hi,

1. Yes I used df -h, that was all.
Here's my quota nano /etc/fstab:

2. Yes, I use <wordpressurl>phpmyadmin but also tried <servername/ip>/phpMyAdmin - same situation.
I have installed Wordfence but will that cause problems with logging to phpMyAdmin itself?

I tried quotaoff -vug /dev/vda2 without restarting server, but nothing changed:


Here's df -i


and df -h once again


I don't know from where 38G comes from...
That's only Wordpress+Woocommerce website, no emails are setup on the server.
Looks like I ran out of space, have no clue why.
How to free disk space?




What can I do?

 

Probably you have a logfile which uses a lot of space. Do you have logrotate installed?
If it is indeed a logfile which takes up all the space, you could copy it to your PC and examine why it is so big. Then clean it with

Code:

> logfile

Attention: This will clean the whole file. Only do this with files that are not needed

 

Thank you!!
Thanks to you and your commands I found big website backup (4G) which I deleted and now I can access both phpmyadmin and Wordpress.

But still log file is huge.
I've deleted .gz log files which was couple of G also.
Can I delete error.log? It's crazy big


> logfile command didn't work

 

See what gets written to that logfile go make it so big. Also see what is the oldest entry there, to see how long it takes to get 18 G worth of logs there. Like this for example

Code:

head error.log
tail error.log

If you have left debug on for the log, that may be one reason why log file get huge rapidly. This has happened to me. It may be there are some errors that happen all the time on your host, resolving those would slow the growth of error.log.
The logrorate application should be able to control growth of logfiles. It clears the log regularly or when it gets too big, depenging on how it is set up.
Is that file apache error.log? Once you have read all you want to know what is inside that file, you can remove it, apache should create it again next time it needs to write some error there.

 

you can, but first, run 'head -n 1 error.log' and check what date/timestamp the first line of that logfile has.
if it's really a long time ago, then you can delete it, and should check your log rotation settings.
the file will get recreated, keep an eye on it, see what errors it's logging. it may be stuff you don't really need to worry about, and can reduce logging levels a bit, or it's something you should look at fixing,
if it's recent, then something is creating a lot of errors, you should really check what errors it's logging and fix them as a priority.

 

ok, looks like @Taleman posted just as I was still typing... just do what he said.

 

Hi,
That's log in /var/log/ispconfig/httpd/mywebsitename

Looks like my theme is causing constant errros/warnings - always the same

Code:

PHP Warning:  Illegal string offset 'lazy_generate_previews' in /var/www/clients/client2/web2/web/wp-content/themes/basel/inc/options/class-options.php on line 295\nPHP message: PHP Warning:  Illegal string offset 'lazy_base_64' in /var/www/clients/client2/web2/web/wp-content/themes/basel/inc/options/class-options.php on line 295

I need to find out what to do with the warning. Right now I have disabled warnings in wp-config file.

Without you I wouldn't figure it out by myself what's wrong. I very appreciate your help!

 

Yes, but you have to restart apache2 afterwards.
You could clean the file without deleting. If you use bash, it should work with the command I gave you above ("> error.log"). Alternatively, you could use the truncate command:

Code:

truncate -s 0 error.log

This truncates the error.log file to a size of 0.

You should resolve the problems in your theme rather than ignoring the warning ;-)

 

without seeing the theme files, I would guess this error started appearing once you started using php7, or php7.2 in particular.
I don't know how old the version of the theme you're using is, I suspect it was written for either php5.6 or php7.0, possibly 7.1, and the syntax has changed a bit in the newer php.
I would suggest finding out if there's a new version of the theme, and if there is, install that.
if not, and you have older versions of php available, I would set the php for that site back to 7.1 see if that fixes the issue. if not try php 7.0 and then php5.6. at the worst, php5.6 should stop the error occurring for now.
then make a staging/dev copy of the site with the lastest php, where you can try to fix the syntax in that class-options.php file, you'll probably need to google that, or find a new theme which will do what you want and will work with php7.2 -> php7.4 and get the site working on that.
if the theme isn't being updated, and you're not confident of changing bits of the code yourself, the only option is a new theme, you can't keep a site running on the old php forever, it'll be too insecure, and newer releases of php will just increase the number of errors the theme creates.

 

Thank you very much all!!
You helped me a lot!

Now it's all looking all right, log file truncated.
I will take a look to PHP version and for a tutorial to install logrorate.

Currently I have no problems with my website
Will see for how much long