Bug with File Uploads in 2.1.7

R

ripkens

Member
#1
#1
After upgrading to 2.1.7 enterprise, File uploads will result in 404 error even if file size is below php.ini settings or lsws tuning settings

We allow file uploads up to 200M which are no problem with our settings. It takes some time but it works fine.

After we got back to 2.1.6 everything is just fine again
 
M

mistwang

LiteSpeed Staff
#2
#2
Is that with LSAPI PHP?

Are you sure it is 404 error? 404 is file not found.

Is there any thing special for the URL for the upload request, like special context, rewritten url etc?

Can you please give 2.1.8 a try, just download the new release by changing the version number.

Thanks,
George
 
R

ripkens

Member
#3
#3
It is with self compiled php 4.3.9 (http://www.mobile2day.de/info.php) running as lsphp (just replaced original one)

The error is 404 because server does not respond to request in any way, so its the same error Firefox gets when not finding a server
"Document contains no data"

The error occurs sometimes after 5 seconds, sometimes after 30, dont know what it is.

It seems that the server behaves like that only if it is under load, on a test IP we "sometimes" could upload a 7M File, on the produktion IP it doesnt even except 1400K
 
R

ripkens

Member
#4
#4
iam getting off work right now, here in germany its already 8PM


good night and if you need mor information, just email me, but i will look here again tommorrow anyways

Marcus
 
M

mistwang

LiteSpeed Staff
#5
#5
It seems that the server behaves like that only if it is under load, on a test IP we "sometimes" could upload a 7M File, on the produktion IP it doesnt even except 1400K
Click to expand...
Does that mean that the problem can be reproduced on your test server with large files? Sometimes it work, sometimes it does not. If so, can you please turn on debug logging on the test server, then send the error.log to bug @ litespeedtech.com. debug logging is not recommended for production server.

To turn on debug logging, the server level "log level" must be set to "DEBUG". then you can use the "Toggle debug lgging" feature or set Server level "Debug level" to "HIGH".

To keep the size of log file minimum, you can keep deleting the lsws/logs/error.log until the problem occur.

If the bug only happens on production under load, it will be much harder to fix.
 
R

ripkens

Member
#6
#6
Hi,

first of all, it took me 5 hours to find out that the error was based on zhe update to 2.1.7. I really checked every logfile i could find on the server to see whats happening - nothing -

I saw the upload process with a grep on my local ip in the stderr but suddenly it just stopped, no error, no warnings.


But i do have some suggestions to make everybodys live easier:

1. Toggle debug mod should also show a state (0,1) to see if it is on or not
2. Place of core dumps should be changeble, our /tmp is only 1G and it run full twice.
3. If Admin email is set, put a checkbox there to define that core dumps are sent with mail, even if core dump is deactivated (override), the server died twice tonight and i dont have core dump because of /tmp might be running full again

I cpuld see in the core files, that there where errors complaining about HTTPS. It said that the page requested is only allowed in HTTPS, checked all vhosts and could not find any errors what this could cause.

I also can not update a produktion IP server to 2.1.7 because we get to many problems with our developer teams due to upload errors.
The test IP could be used, but the error seems to be harder on load. On the test IP where only me is on the server, we can reproduce the error but it is different behaviour. Sometimes the upload works, sometimes it doesnt, and if it fails i dont see anything in the DEBUG log.
So i suggest implement suggestion No 3 to make it easier to debug.


Marcus
 
M

mistwang

LiteSpeed Staff
#7
#7
Hi Marcus,

Sorry about that.

When admin email is set, lshttpd should only keep the latest 10 core files, we will reduce it to 5. Sometime the core file is just too big to be sent in a email. changing the core file directory is a good idea.

If you don't mind please send us the core files you have for analysis, at least the back trace from the email.

Please make sure that the "Log Level" has been set to "DEBUG" at server level and vhost level, otherwise you will not see any debug message in the log.

Thank you for your help.
George
 
R

ripkens

Member
#8
#8
I had hundreds of core dumps.

i had to delete them all to get the server working and then i disabled the core dump. That means i dont have a dump right now.

But i get Emails everey couple hours with this:

At [21/Dec/2005:16:12:51 +0100], web server with pid=14825 received unexpected signal=11, no core file is created. A new instance of web server will be started automatically!

At [21/Dec/2005:16:02:40 +0100], web server with pid=12112 received unexpected signal=11, no core file is created. A new instance of web server will be started automatically!
 
M

mistwang

LiteSpeed Staff
#9
#9
I guess the hundreds of core files you got is before you set the admin email, don't you?

It should be ok to enabled core dump once the admin email is set, as long as your /tmp has enough space left for maximum 10 core files.

If you do mind, please enable core dump, maybe temporarily, we need to analyze the core or the backtrace to fix the bug.

And please switch to the debug build of lshttpd before enable core dump, you can found the debug build binary in the installation package, lsws-2.1.x/bin/lshttpd.dbg. please copy it over to where lshttpd is installed then change the symbolic link "lshttpd" to "lshttpd.dbg".

Once we identify the location of bug, we will fix it quickly.

Thanks,
George
 
M

mistwang

LiteSpeed Staff
#11
#11
Please tell me which version/edition of LSWS is used, I tried the core files with different binaries, does not work.

If there is any back trace information in the email you received, please forward.

I think you upload problem probably is related to the /tmp directory, as PHP store uploaded files in a temp directory, usually /tmp, it will cause upload problem when /tmp is full or close to full. May not be the fault of 2.1.7.

Anyway, if you don't mind, you can try 2.1.8 release, which only keep up to 5 latest core file in /tmp, only likely to fill up /tmp partition. It is at http://www.litespeedtech.com/packages/2.1/lsws-2.1.8-ent-i386-linux.tar.gz .
 
R

ripkens

Member
#12
#12
The version used is 2.1.6 ent dbg

The /tmp was cleaned up when we encountered the error to be the fault of 2.1.7

I cant use any version beyond 2.1.6 until i can be sure the upload problem is solved in any way, Our developer Teams will just kick our butts to hell.
 
R

ripkens

Member
#13
#13
At [21/Dec/2005:19:38:04 +0100], web server with pid=20213 received unexpected signal=11, a core file is created. A new instance of web server will be started automatically!

Please forward the following debug information to bug@litespeedtech.com.
Environment:

Server: LiteSpeed/2.1.6 Enterprise
OS: Linux
Release: 2.4.21-4.ELsmp
Version: #1 SMP Fri Oct 3 17:52:56 EDT 2003
Machine: i686

If the call stack information does not show up here, please compress and forward the core file located in /tmp/lshttpd/.

Using host libthread_db library "/lib/tls/libthread_db.so.1".
Core was generated by `lshttpd'.
Program terminated with signal 11, Segmentation fault.
#0 0x0809c74d in HttpContext::getDefaultCharset (this=0x8583664)
at /home/gwang/crossrel/release/httpd/httpd/http/httpcontext.h:278
in /home/gwang/crossrel/release/httpd/httpd/http/httpcontext.h
#0 0x0809c74d in HttpContext::getDefaultCharset (this=0x8583664)
at /home/gwang/crossrel/release/httpd/httpd/http/httpcontext.h:278
#1 0x0809bfb2 in HttpReq::getDefaultCharset (this=0x8267dd4)
at /home/gwang/crossrel/release/httpd/httpd/http/httpreq.cpp:2763
#2 0x0807c097 in HttpCgiTool::processHeaderLine (pResp=0x8267fac,
pReq=0x8267dd4, pLineBegin=0x84df647 "Content-Type: image/gif",
pLineEnd=0x84df65e "", status=@0x82987dc)
at /home/gwang/crossrel/release/httpd/httpd/http/httpcgitool.cpp:99
#3 0x080d572c in LsapiConn::processRespHeader (this=0x84df4c4,
pEnd=0x84df6f2 " OUR STP PUR\"", status=@0x82987dc)
at /home/gwang/crossrel/release/httpd/httpd/extensions/lsapi/lsapiconn.cpp:690
#4 0x080d58c1 in LsapiConn::processRespHeader (this=0x84df4c4)
at /home/gwang/crossrel/release/httpd/httpd/extensions/lsapi/lsapiconn.cpp:727
#5 0x080d5399 in LsapiConn::processResp (this=0x84df4c4)
at /home/gwang/crossrel/release/httpd/httpd/extensions/lsapi/lsapiconn.cpp:600
#6 0x080d4806 in LsapiConn::doRead (this=0x84df4c4)
at /home/gwang/crossrel/release/httpd/httpd/extensions/lsapi/lsapiconn.cpp:302
#7 0x080b84c2 in ExtConn::eek:nRead (this=0x84df4c4)
at /home/gwang/crossrel/release/httpd/httpd/extensions/extconn.cpp:202
#8 0x080b998d in EdStream::handleEvents (this=0x84df4c4, event=1)
at /home/gwang/crossrel/release/httpd/httpd/edio/ediostream.cpp:70
#9 0x080bb6a2 in PollfdReactor::processAllEvents (this=0x82992a4)
at /home/gwang/crossrel/release/httpd/httpd/edio/pollfdreactor.h:143
#10 0x080bb497 in Poller::waitAndProcessEvents (this=0x829929c,
iTimeoutMilliSec=1000)
at /home/gwang/crossrel/release/httpd/httpd/edio/poller.cpp:69
#11 0x08088d2a in EventDispatcher::run (this=0x82745d0)
at /home/gwang/crossrel/release/httpd/httpd/http/eventdispatcher.cpp:143
#12 0x0805f36f in HttpServerImpl::start (this=0x82745bc)
at /home/gwang/crossrel/release/httpd/httpd/main/httpserver.cpp:297
#13 0x08061d0e in HttpServer::start (this=0x8237f60)
at /home/gwang/crossrel/release/httpd/httpd/main/httpserver.cpp:1535
#14 0x0804e203 in LshttpdMain::main (this=0x8270088, argc=1, argv=0xbfffcdb4)
at /home/gwang/crossrel/release/httpd/httpd/main/lshttpdmain.cpp:1095
#15 0x0804ba02 in main (argc=1, argv=0xbfffcdb4)
at /home/gwang/crossrel/release/httpd/httpd/main.cpp:105
 
R

ripkens

Member
#17
#17
I just upgraded all 3 Servers to 2.1.9.

We will see if i still get core dumps.

I just tried to upload a 14 MB File which seems to work fine now...
 
You must log in or register to reply here.
Top