If php-fastcgi won’t come to the IP:port, the socket will come to the php-fastcgi

I’ve had an unusual problem with lighttpd-1.4.35p2-ldap-mysql and php-fastcgi-5.4.30 on an OpenBSD 5.6 amd64: php-fastcgi-5.4.30 was refusing to use/bind to an otherwise perfectly available address and port no matter what, with similar to the following in the logs:

(mod_fastcgi.c.984) bind failed for: tcp: Can’t assign requested address

That was ridiculous, because

a) none of the methods would give even a smallest hint that the IP and port were somehow and somewhere in use,
b) changing the IP, the port, or any other parameter for the server.bind, server.port, or the fastcgi.server section would make a difference – exactly the same message would emerge again in the log, only with the new parameters.

The socket, though, works just fine, so, in order to stop spending time on debugging of such a bizarre behaviour, I simply switched to the socket method.

However, I’d really like to read an explanation for this particular mystery. Any ideas? Or I simply have to start somewhere before the line 984 of the mod_fastcgi.c?

Leave a Reply

Your email address will not be published. Required fields are marked *