[Resolved] Individual virtual hosts crashing with 4.2.9

Status
Not open for further replies.
W

wanah

Well-Known Member
#1
#1
Hello,

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 :)
 
W

wanah

Well-Known Member
#2
#2
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.
 
W

wanah

Well-Known Member
#3
#3
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…
 
W

wanah

Well-Known Member
#4
#4
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…
 
M

mistwang

LiteSpeed Staff
#5
#5
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...
 
M

mistwang

LiteSpeed Staff
#7
#7
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.
 
W

wanah

Well-Known Member
#8
#8
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…
 
W

wanah

Well-Known Member
#10
#10
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.
 
Status
Not open for further replies.
Top