2.0.1 as stable as 2.0?

[ts77]

Hi there,

I just upgraded one dev-server through the web-interface and sice then I already got more than 10 times

Web server with pid=13094 received unexpected signal=11, no core file is created. A new instance of web server will be started automatically!

(always with different pid for sure )

Was there anything changed which could cause this?
The server is not really loaded, it doesn't even do 1 req/s ... .
Anything I could do to track this down?
I don't really want to upgrade the production server and seeing the same result .


TIA,

thomas

 

[mistwang]

It probably caused by the new error logging code, but I am not 100% sure.
That will be great if you can send us a core file, if interested please follow the direction in http://www.litespeedtech.com/bugs.html

If you are using a stock Redhat kernel, then forget about it, as the kernel is patched not to dump a core for set uid process no matter what.

Thanks!

 

[ts77]

as you can see from my post

no core file is created

the core-file is not being created.

No, I'm not using redhat ... its a gentoo-linux running on kernel 2.6.11.
How can I enable the core-dumps there?
Your bug-page only talks about enabling it for 2.4.x.

Strange thing is that it didn't segfault for 14 hours now ... before it did this every 10 minutes :shock: .

 

[mistwang]

You can enable core dump the same way for 2.6 kernel from the admin interface. If the kernel is not patched disallowing it, the error log will report "core dump is enabled." when you restart the server.

 

[ts77]

yeah, that worked and I just got a couple more of these segfaults right now.
message to bugs@... is on its way .



another related question:
On the other machine the webupdate to 2.0.1 didn't work.
It told that its upgrading, restarted the server and ... its still 2.0.0 and in the bin-directory there is no trace of 2.0.1.
Any idea what could be wrong about this? Are upgrade-attempts (or better their results) logged somewhere?


TIA,

thomas

 

[mistwang]

On the other machine the webupdate to 2.0.1 didn't work.
It told that its upgrading, restarted the server and ... its still 2.0.0 and in the bin-directory there is no trace of 2.0.1.
Any idea what could be wrong about this? Are upgrade-attempts (or better their results) logged somewhere?

You can check lsws/autoupdate/update.log, but I not sure anything useful to diagnose this problem is logged there.
The update package should be expanded under lsws/autoupdate/ directory.
Please check the error.log regarding update as well.

Another thing to try is to restart the web server from console.

 

[ts77]

hmm, damned. there is nothing in the logs shown about it and nothing extracted in autoupdate.
restarting webserver from console didn't help either.

some additional tools needed which might be outdated or missing on debian-stable?

maybe I should just use the manual installation/upgrade from console .

 

[mistwang]

The lshttpd will execute lsws/admin/misc/update.sh when the update request has been received.
You can try that script from console, see what kind of error it reports.

 

[ts77]

wanna know what that script returned?

nothing ... it just worked and upgraded without problems.
Don't know what happened ... we will see after the next release .

 

[mistwang]

Is the server started as root users? Maybe because insufficient permission.
Another possibility is that lshttpd does not execute it at all due to authentication problem, that should be logged in the error.log.

 

[ts77]

as I'm putting a bit more load on litespeed-webserver I just got this:
---
At [10/Apr/2005:16:52:32 +0200], web server with pid=7340 received unexpected signal=6, no core file is created. A new instance of web server will be started automatically!
---
... running 2.0.2 .

Does anyone know what could cause a "signal 6" ?
Thats running kernel 2.4.28 on a debian-stable.


Thanks,

thomas

 

[zellster]

Signal 6 is SIGABRT, which is typically triggered by a false assert() or a direct call to abort().

 

[ts77]

ok, thanks.
so the question to the litespeed-developers remains,
where in the litespeed-code could that happen?
I wasn't really able to reproduce this ... just got it two times yesterday.

 

[mistwang]

Yes, that's cause by assert() calls, assert() are used somewhere to guard against something not suppose to happen.
I can pin-point the location if you can send me a core dump, just enable core dump from the admin interface.

Thanks.

 

[ts77]

damned, I just go this again but still even though I had enabled core-dumps in the admin I didn't get one. The same for a segfault I had two days ago.

does anyone know how to convince a grsec-enabled kernel to produce core-files?

 

[mistwang]

I think there is no easy way to allow it other than recompiling the kernel with corresponding patch removed, at least for a redhat kernel.

However, the failed conditions are logged into stderr.log for assert() failures, so please search your stderr.log and let me know the related output. If it is a "POLLOUT" related failure, it has been fixed in current 2.1RC1.

 

[ts77]

ah, that gave some mesages .
message to bugs is on its way.

 

[mistwang]

Please try updated 2.1RC1.