Using SHMTL file in VH gives signal 11 on child process


Well-Known Member

I'm experiencing a problem with versions 4.0b2 and 4.0b3 when using SHTML files on virtual hosts. When I try to access an shtml file in a normal virtual host, I get the following error in my server log and no content is sent to the client.

2009-01-07 22:14:42.670 [NOTICE] [AutoRestarter] child process with pid=21424 received signal=11, no core file is created!
2009-01-07 22:14:42.670 [NOTICE] [AutoRestarter] cleanup children processes and unix sockets belong to process 21424 !
2009-01-07 22:14:42.670 [INFO] [AutoRestater] Clean up child process with pid: 21435
2009-01-07 22:14:42.772 [NOTICE] [child: 21439] Successfully change current user to lsws
2009-01-07 22:14:42.772 [NOTICE] [Child: 21439] Core dump is disabled.
2009-01-07 22:14:42.772 [NOTICE] [Child: 21439] Setup swapping space...
2009-01-07 22:14:42.772 [NOTICE] [Child: 21439] LiteSpeed/4.0b3 Standard starts successfully!
2009-01-07 22:14:42.784 [NOTICE] [AutoRestarter] new child process with pid=21439 is forked!
However, if I use exactly the same configuration on the same server when run under a virtual host template, the SHTML pages are displayed correctly with the SSI code inserted. All other pages on the site are displayed as expected, it's only SHTML pages and only when they are instantiated virtual hosts.

I'm using Ubuntu 8.04, and have tested the above on both 4.0b2 and 4.0b3 (standard) and am experiencing the same problem with both versions.

I've sent you a link to the core dump file.
Last edited:


LiteSpeed Staff
there have been many updates on 4.0b3 release package, you can try the latest one, if the problem persist, we will investigate.


Well-Known Member
This is the version I've been using - but I checked both versions 4.0b2 and 4.0b3. I think the core dump link I sent you was for version 4.0b2 though, as I checked that one after 4.0b3.

I'll do another one for 4.0b3 and send you that link via email.


LiteSpeed Staff
checked the core file, it does not match our current 4.0b3 binary. realized that the latest update of 4.0b3 has not been uploaded to your server. Just did that, please download and try again.


Well-Known Member
I've downloaded the latest binary, and all is well.

I didn't realise that binaries of the same name might be different. If you're going to do that, have you thought of adding some additional numbering

e.g. 4.0b3.1, 4.0b3.2...

Do the production versions also sometimes differ in between the numbered updates, i.e. is version 3.3.23 currently different to a few weeks ago?