On 3/1/06, Mohammad K. email@example.com wrote:
for 30 seconds given 3 attempts, its restart interval has been backed
off to 600 seconds
Until you get dispatch.fcgi to properly fail in the absense of a
webserver I would not even experiment with the webserver.
Try to stop all apache / lighttpd webserver instances and then run
“ruby dispatch.fcgi” again.
AIUI, dispatch.fcgi should be attempting to connect to a socket that
is provided by the now non-existent webserver. Since the socket does
not have a listener it should error out with the “Error 500: Internal
Server Error” message that I stated before.
If dispatch.fcgi is simply exiting with no error message you still
have something wrong in your fcgi setup that has nothing to do with
At that point you will need to be posting what env. (OS, distro, etc.)
you are working with and what you did to get your fcgi setup going.
Getting fcgi setup seems to be very specific to the OS and distro. I
have only set it up once and that is on a Suse 10.0 setup, so I’m not
sure I’m the one to help.
FYI: AIUI, when things are working the webserver creates the sockets
and establishes listens on them. Then the fcgi processes are started
by the webserver in the background. They in turn connect to the
sockets. The fcgi processes should be long lived (hours/days/weeks)
and able to handle repeated requests for fcgi service from the
The Norcross Group
Forensics for the 21st Century