phpMyAdmin - Error session_write_close()

Discussion in 'Installation/Configuration' started by Profesor Proton, Jan 30, 2020.

  1. Profesor Proton

    Profesor Proton New Member

    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/
     

    Attached Files:

    Last edited: Jan 30, 2020
  2. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    did you check the disk space on /var/lib/php (probably /var or /)? sounds like you're out.
     
  3. Profesor Proton

    Profesor Proton New Member

    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
     
  4. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    Is quota used and that user is over quota?
     
  5. Profesor Proton

    Profesor Proton New Member

    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
     
  6. Profesor Proton

    Profesor Proton New Member

    Anyone can help? :(
     
  7. nhybgtvfr

    nhybgtvfr Well-Known Member HowtoForge Supporter

    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.
     
  8. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    Also check inode use (df -i), as running out of inodes returns the same error as running out of disk space.

    If that and the other suggestions turn up nothing, you might need to move your troubleshooting up a level from the server environment to vps limits, if applicable. Eg. some container types can oversubscribe disk space allocation or such.
     
  9. Profesor Proton

    Profesor Proton New Member

    Hi,

    1. Yes I used df -h, that was all.
    Here's my quota nano /etc/fstab:
    upload_2020-2-5_20-50-56.png
    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:
    upload_2020-2-5_20-54-27.png

    Here's df -i
    upload_2020-2-5_20-41-38.png

    and df -h once again
    upload_2020-2-5_20-46-37.png

    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?
    upload_2020-2-5_21-0-58.png

    upload_2020-2-5_21-7-26.png

    What can I do?
     

    Attached Files:

  10. Jesse Norell

    Jesse Norell ISPConfig Developer Staff Member ISPConfig Developer

    Looks like the majority of use is in /var, which is typical. Just start there and see what is using the most space, and keep going further down directory levels till you find it.

    du -sk /var/* | sort -n
     
  11. Steini86

    Steini86 Active Member

    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 ;)
     
  12. Profesor Proton

    Profesor Proton New Member

    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
    upload_2020-2-7_20-51-50.png

    > logfile command didn't work
     
  13. Taleman

    Taleman Well-Known Member HowtoForge Supporter

    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.
     
  14. nhybgtvfr

    nhybgtvfr Well-Known Member HowtoForge Supporter

    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.
     
  15. nhybgtvfr

    nhybgtvfr Well-Known Member HowtoForge Supporter

    ok, looks like @Taleman posted just as I was still typing...:D just do what he said. :)
     
    Profesor Proton and Taleman like this.
  16. Profesor Proton

    Profesor Proton New Member

    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! :)
     
  17. Steini86

    Steini86 Active Member

    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 ;-)
     
  18. nhybgtvfr

    nhybgtvfr Well-Known Member HowtoForge Supporter

    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.
     
  19. Profesor Proton

    Profesor Proton New Member

    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 ;)
     

Share This Page