[solved] Individual virtual hosts crashing with 4.2.9

Discussion in 'Bug Reports' started by wanah, Apr 13, 2014.

  1. wanah

    wanah Well-Known Member


    We updated litespeed 4.2.6 that was working fine to litespeed 4.2.9, four days ago and since then random sites have stopped responding. Restarting litespeed resolves the problem but doesn't give a reason for the problem.

    The error log is empty (well not empty but no real errors) and there are no coredumps created.

    Any suggestions how I can get more info so you have help find a solution ? (two customers have contacted us so far complaining that their site was not responding and each time we just restarted litespeed.

    We're using lsphp version that came with 11.26 on CloudLinux 6 in the processgroup mode.

    Thanks :)
  2. wanah

    wanah Well-Known Member

    It's just happened again, another cutomer contacted me about their site not showing.

    I've force a reinstall to the latest 4.2.9 version but have no idea if anything has changed or if it's the exact same version as I updated to 5 days ago.

    I can't wait for thier to be build numbers as just knowing that I had 4.2.9 build 123 and that the new version was 4.2.9 build 145 would have let me know that some things had changed.
  3. wanah

    wanah Well-Known Member

    I've increased the log level reporting and will see if I catch anything next time it happens.

    I went through everything I did since the setup and remembered that I created a new gzip cache tempfs folder because the previous one was using 100% of the 10K innodess I had allowed it. I set the new one to 200K innodes but it seems that I set the wrong group for the folder, it was owend by nobody:nobody whereas I think is supposed to be owned by nobody:lsadm

    Will see if this fixes the issue…
  4. wanah

    wanah Well-Known Member

    Well no, it seems that it was set to nobody:nobody as soon as litespeed is set to use this directory.

    I've just set it to /dev/shm/lsgzip

    And the folder is also created with nobody:nobody so I guess this was not the issue and that it could be the 4.2.9 version that has issues…
  5. mistwang

    mistwang LiteSpeed Staff

    When it happen again, please do

    killall -USR2 litespeed

    to turn on debug logging dynamically, the "Log Level" need to be set to "DEBUG" before hand.
    Send a request to reproduce the problem, then grep your IP in /usr/local/apache/logs/error_log. send the grep result to bug@litespeed...
  6. wanah

    wanah Well-Known Member


    I've just sent you the logs as it happened this morning
  7. mistwang

    mistwang LiteSpeed Staff

    FYI, It more likely an APC configuration issue for the PHP ProcessGroup of that account.
    PHP error_log have entries like "PHP Warning: Unknown: Unable to allocate memory for pool. in Unknown on line 0" which is from APC cache, php.ini tuning may take care of it.
  8. wanah

    wanah Well-Known Member

    I've remplaced /tmp/apc.XXXXXX with /dev/shm/apc.XXXXXX will see if this improves the situation as we have much more available space in free memory then in our /tmp directory…
  9. NiteWave

    NiteWave Administrator

  10. wanah

    wanah Well-Known Member

    It's PHP 5.3, on PHP 5.4 we use opcache.

    Since we've moved it away from our tmp partition which was probably too small we haven't had any complaints about sites not working :)

    I believe in 4.2.6 this problem was not noticed and php was restarted where as in 4.2.9 php didn't crash anymore and just gave an error without restarting php and thus not freeing any cache disk space.

Share This Page