Issue #894 resolved

can't configure [apache] dynamic FCGI, only static and external

Anonymous created an issue

Seems that cherryd always passes BindAddress, either as a Unix domain socket, or as an (ip,port). To configure flup for dynamic FCGI (the most standard kind), one must not pass BindAddress.

Hacking past this reveals corresponding issues in the start listener, which dies when there is no socket configured, it seems.

This prevents CherryPy from being used on bluehost, one of the fastest growing web hosting companies around.

Reported by v+python

Comments (12)

  1. Robert Brewer

    My first thought is to change CP such that server.sock_file,, and server.port can all be explicitly set to None to trigger the 'dynamic mode' of FCGI (but will still be the default if not explicitly 'None'). This may require some trawling through the whole codebase to see what other bits assume either host+port or sock_file is set, but shouldn't be too much work.

  2. Anonymous

    After a couple comments on the group, and more reflection, I think explicitly specifying the mode is easier to understand. Then, given the mode, setting the appropriate other options is straightforward. Inferring the mode from which settings are set is confusing and error-prone.

  3. guest

    It is not clear what bind_addr should be passed to ServerAdapter when the FCGI server gets no bindAddress. This should be documented when this bug is fixed.

  4. Robert Brewer

    Fixed in [2126]. After much thought, I decided to use None, because that reflects best what's actually happening with dynamic FastCGI: the CP process has no host, no port, and no single named socket (each child spawned by Apache has its own domain socket on Unix, or its own named pipe on Windows).

    The above changeset also adds "bind_addr" as a first-class attribute to the cherrypy.server API. Getting the value draws from socket_host/port/file; setting it causes those values to change appropriately.

    Finally, I added apache-fcgi.conf to the scaffold directory. It uses FastCGIExternalServer because that's the only route that's reasonably cross-platform.

    Please keep us posted on how the above works with Bluehost.

  5. Anonymous

    After wading through a number of other minor changes for 3.2 upgrade stuff, I adjusted my socket_port and socket_host to be None, which is the rule for the patch applied for this issue, I obtained:

    'Dynamic FCGI server not available on this platform. ' ValueError: Dynamic FCGI server not available on this platform. You must use a static or external one by providing a legal bindAddress.

    This seems to be produced as a result of the following code in, and I don't have a clue what the "hasattr" is really testing, or what socket.socket might actually be when first imported, nor what "fromfd" means, either.

        def __init__(self, *args, **kwargs):
            if kwargs.get('bindAddress', None) is None:
                import socket
                if not hasattr(socket.socket, 'fromfd'):
                    raise ValueError(
                        'Dynamic FCGI server not available on this platform. '
                        'You must use a static or external one by providing a '
                        'legal bindAddress.')
            self.args = args
            self.kwargs = kwargs
            self.ready = False

    What I think I know, is that bluehost uses dynamic FCGI, which I think means that the input comes from stdin, which is opened to a socket created by Apache for communication with Apache.

    What I know from testing, is that If I comment out the "if not hasattr" section of the code, that it works.

    I attached my versions of the files and cherryd that include this commenting out, and also CGI support, which would be nice to add, even thought it is off topic for this ticket. Should I make a new ticket for that?

  6. guest

    cut-n-paste error in (a rename of cherryd)

    f = servers.FlupCGIServer(application=cherrypy.tree)

    instead of the two parameter version found there. Would sure be nice to figure out the appropriate time and API to exit this server after it serves its request, though, because other than the processes hanging around, which seems to sometimes cause a hang on the browser too, it seems to be functional.

    And my test environment is such that I can test any patches quickly, if you come up with one. I haven't figured out the engine stuff well enough to have a clue.

  7. Log in to comment