public httpd daemon stops responding/process controls broken

Discussion in 'Install/Configuration' started by eweaverp, May 17, 2005.

  1. eweaverp

    eweaverp New Member


    I am running Litespeed Standard (Free) 2.04 on Solaris 2.9, on a 32-bit SunBlade 150. When I had gz compression turned on, the public server would never finish sending a page (as far as I can tell). It would send all the data but never close the connection.

    With gz turned off, things seem to work fine, except that after a while (so many pages served? so many cgi processes? i dunno) the public server completely stops responding. The connections are not refused; just nothing happens.

    The webadmin daemon has worked fine the whole time, except for a while when it didn't send the entire page for the tabbed server configs. I don't remember what setting was causing that.

    Any clues? Right now I wrote a cron script that checks for a non-existant page and stops and starts the server if it doesn't get a 404 response. But that is pretty kludgy.

    Also, the webadmin process controls don't work at all. Restart doesn't actually restart, and reload returns a blank page. This happens in both Firefox and Internet Explorer.

    I'm perplexed.


  2. mistwang

    mistwang LiteSpeed Staff

    Thank you for your feedback.

    Are you using /dev/poll as the event dispatcher? please use poll for now.

    Is the compression for static content or dynamic content?

    Currently our sparc/solaris environment is not available, we will check those issues wn our environment is ready.
  3. eweaverp

    eweaverp New Member

    I am using poll.

    The compression issues for were both static and dynamic content.

    I can send you my httpd_conf.xml (spelling?) file if you want.
  4. mistwang

    mistwang LiteSpeed Staff

    If your server is not that busy, can you please turn on debug logging by setting "debug level" to high, once the problem start to occur, remove lsws/logs/error.log, (new one will be created automatically), let it run for a while, then send us the error log. Be careful, the debug log will fill up your disk very quickly. :)

Share This Page