Re: 2.4.x with uds patch; FastCGI broken?
Thx for the bug report... I'll investigate. On Nov 15, 2013, at 8:11 PM, Kyle Johnson osma...@gmail.com wrote: I've been attempting to test the uds support on 2.4.x with the uds patch (http://people.apache.org/~jim/patches/uds-2.4.patch). I'm assuming HTTP works (it would appear based on the mailing list that the author has been tested it with HTTP). However, when I try using fcgi the socket appears to be lost somewhere. Example config line: ProxyPass / unix:/var/run/php/php-fpm.sock|fcgi://localhost/www/ And the error log with debugging on (browsing to http://localhost/index.php): [proxy:debug] [pid 30127:tid 140367020521216] proxy_util.c(1773): AH00925: initializing worker unix:/var/run/php/php-fpm.sock|fcgi://localhost/www/ shared [proxy:debug] [pid 30127:tid 140367020521216] proxy_util.c(1815): AH00927: initializing worker unix:/var/run/php/php-fpm.sock|fcgi://localhost/www/ local [[proxy:debug] [pid 30127:tid 140367020521216] proxy_util.c(1850): AH00930: initialized pool in child 30127 for (localhost) min=0 max=64 smax=64 [proxy_fcgi:debug] [pid 30116:tid 140366778955520] mod_proxy_fcgi.c(73): [client 66.192.178.3:54534] AH01060: set r-filename to proxy:fcgi://localhost:8000/www/index.php [proxy:debug] [pid 30116:tid 140366778955520] mod_proxy.c(1104): [client 66.192.178.3:54534] AH01143: Running scheme fcgi handler (attempt 0) [proxy_fcgi:debug] [pid 30116:tid 140366778955520] mod_proxy_fcgi.c(764): [client 66.192.178.3:54534] AH01076: url: fcgi://localhost:8000/www/index.php proxyname: (null) proxyport: 0 [proxy_fcgi:debug] [pid 30116:tid 140366778955520] mod_proxy_fcgi.c(774): [client 66.192.178.3:54534] AH01078: serving URL //localhost:8000/www/index.php [proxy:debug] [pid 30116:tid 140366778955520] proxy_util.c(2101): AH00942: FCGI: has acquired connection for (*) [proxy:debug] [pid 30116:tid 140366778955520] proxy_util.c(2176): [client 66.192.178.3:54534] AH00944: connecting //localhost:8000/www/index.php to localhost:8000 [proxy:debug] [pid 30116:tid 140366778955520] proxy_util.c(2311): [client 66.192.178.3:54534] AH00947: connected /www/index.php to localhost:8000 [proxy:error] [pid 30116:tid 140366778955520] (111)Connection refused: AH00957: FCGI: attempt to connect to 127.0.0.1:8000 (*) failed [proxy_fcgi:error] [pid 30116:tid 140366778955520] [client 66.192.178.3:54534] AH01079: failed to make connection to backend: localhost [proxy:debug] [pid 30116:tid 140366778955520] proxy_util.c(2139): AH00943: FCGI: has released connection for (*) If I switch from fcgi to http, I get a log that's a bit different and see some lines which lead me to believe the uds is simply lost somewhere in the fcgi setup that it isn't in the http setup (this errors out as the socket is expecting fcgi, not http): ProxyPass / unix:/var/run/php/php-fpm.sock|http://localhost/www/ [proxy:debug] [pid 30707:tid 139930058049280] proxy_util.c(1773): AH00925: initializing worker unix:/var/run/php/php-fpm.sock|http://localhost/www/ shared [proxy:debug] [pid 30707:tid 139930058049280] proxy_util.c(1815): AH00927: initializing worker unix:/var/run/php/php-fpm.sock|http://localhost/www/ local [proxy:debug] [pid 30707:tid 139930058049280] proxy_util.c(1850): AH00930: initialized pool in child 30707 for (localhost) min=0 max=64 smax=64 [proxy:debug] [pid 30721:tid 139929963685632] mod_proxy.c(1104): [client 66.192.178.3:54544] AH01143: Running scheme http handler (attempt 0) [proxy:debug] [pid 30721:tid 139929963685632] proxy_util.c(2101): AH00942: HTTP: has acquired connection for (localhost) [proxy:debug] [pid 30721:tid 139929963685632] proxy_util.c(2115): AH02545: HTTP: has determined UDS as /var/run/php/php-fpm.sock [proxy:debug] [pid 30721:tid 139929963685632] proxy_util.c(2176): [client 66.192.178.3:54544] AH00944: connecting http://localhost/www/index.php to localhost:80 [proxy:debug] [pid 30721:tid 139929963685632] proxy_util.c(2311): [client 66.192.178.3:54544] AH00947: connected /www/index.php to localhost:80 [proxy:error] [pid 30721:tid 139929963685632] (2)No such file or directory: AH02454: HTTP: attempt to connect to Unix domain socket /var/run/php/php-fpm.sock (localhost) failed [proxy:error] [pid 30721:tid 139929963685632] AH00959: ap_proxy_connect_backend disabling worker for (localhost) for 60s [proxy_http:error] [pid 30721:tid 139929963685632] [client 66.192.178.3:54544] AH01114: HTTP: failed to make connection to backend: localhost [proxy:debug] [pid 30721:tid 139929963685632] proxy_util.c(2139): AH00943: HTTP: has released connection for (localhost) Note in this case the line HTTP: has determined UDS as /var/run/php/php-fpm.sock which is missing from the fcgi case. Digging through the code is proving difficult for me to trace where the path for fcgi breaks down vs http. As an aside, I'm fairly certain that in the case of a fcgi something to the effect of:
Re: 2.4.x with uds patch; FastCGI broken?
The below is the pertinent parts: On Nov 15, 2013, at 8:11 PM, Kyle Johnson osma...@gmail.com wrote: [proxy_fcgi:debug] [pid 30116:tid 140366778955520] mod_proxy_fcgi.c(764): [client 66.192.178.3:54534] AH01076: url: fcgi://localhost:8000/www/index.php proxyname: (null) proxyport: 0 [proxy_fcgi:debug] [pid 30116:tid 140366778955520] mod_proxy_fcgi.c(774): [client 66.192.178.3:54534] AH01078: serving URL //localhost:8000/www/index.php [proxy:debug] [pid 30116:tid 140366778955520] proxy_util.c(2101): AH00942: FCGI: has acquired connection for (*) ... [proxy:debug] [pid 30721:tid 139929963685632] proxy_util.c(2101): AH00942: HTTP: has acquired connection for (localhost) From this, it looks like fcgi is trying to use the general reverse proxy worker (proxy:reverse has the name *)... So I'm guessing it's something between how http and fcgi look for their worker. That gives me an idea where to look.
Re: 2.4.x with uds patch; FastCGI broken?
On Nov 15, 2013, at 8:11 PM, Kyle Johnson osma...@gmail.com wrote: [proxy_fcgi:debug] [pid 30116:tid 140366778955520] mod_proxy_fcgi.c(73): [client 66.192.178.3:54534] AH01060: set r-filename to proxy:fcgi://localhost:8000/www/index.php Also need to see if the above is a factor...
Re: 2.4.x with uds patch; FastCGI broken?
OK, I think I know what it is, and it's simple (if true), but a pain. The issue is that during the proxypass stuff, we tuck away the name, which may, or may not, include a port designation, depending on if the URL passed does. All well and good. The problem is that during the proxy_hook_canon_handler() phase, some submodules, like fcgi, always attach the port to the URL if it doesn't include one. http does not; it only adds it iff the determined port != the default port. Soo when mod_proxy tries to find the correct worker, because the fcgi URL in ProxyPass didn't have :8000 but the canon URL will have it added, they will be see as different, and so the defined worker will not be used; the default and generic reverse proxy worker will. We could ensure that when each worker is defined, we always add the port, even if not provided. But, this will involve changing proxy_http_canon(). I'm not sure I like this since it adds additional storage for no real purpose, plus adds some cycles to the strcasecmp for finding the workers. Instead, I think that fcgi (and ajp as well), should do their proxy_*_canon the same as http. However, since apr_uri_port_of_scheme() doesn't know about these, we need to also create a ap_proxy_port_of_scheme(). Unless I hear otherwise, that's what I'll be working on.
Re: 2.4.x with uds patch; FastCGI broken?
FWIW, this isn't related to UDS at all, except that we found this bug due to UDS. On Nov 16, 2013, at 12:47 PM, Jim Jagielski j...@jagunet.com wrote: OK, I think I know what it is, and it's simple (if true), but a pain. The issue is that during the proxypass stuff, we tuck away the name, which may, or may not, include a port designation, depending on if the URL passed does. All well and good. The problem is that during the proxy_hook_canon_handler() phase, some submodules, like fcgi, always attach the port to the URL if it doesn't include one. http does not; it only adds it iff the determined port != the default port. Soo when mod_proxy tries to find the correct worker, because the fcgi URL in ProxyPass didn't have :8000 but the canon URL will have it added, they will be see as different, and so the defined worker will not be used; the default and generic reverse proxy worker will. We could ensure that when each worker is defined, we always add the port, even if not provided. But, this will involve changing proxy_http_canon(). I'm not sure I like this since it adds additional storage for no real purpose, plus adds some cycles to the strcasecmp for finding the workers. Instead, I think that fcgi (and ajp as well), should do their proxy_*_canon the same as http. However, since apr_uri_port_of_scheme() doesn't know about these, we need to also create a ap_proxy_port_of_scheme(). Unless I hear otherwise, that's what I'll be working on.
2.4.x with uds patch; FastCGI broken?
I've been attempting to test the uds support on 2.4.x with the uds patch ( http://people.apache.org/~jim/patches/uds-2.4.patch). I'm assuming HTTP works (it would appear based on the mailing list that the author has been tested it with HTTP). However, when I try using fcgi the socket appears to be lost somewhere. Example config line: ProxyPass / unix:/var/run/php/php-fpm.sock|fcgi://localhost/www/ And the error log with debugging on (browsing to http://localhost/index.php ): [proxy:debug] [pid 30127:tid 140367020521216] proxy_util.c(1773): AH00925: initializing worker unix:/var/run/php/php-fpm.sock|fcgi://localhost/www/ shared [proxy:debug] [pid 30127:tid 140367020521216] proxy_util.c(1815): AH00927: initializing worker unix:/var/run/php/php-fpm.sock|fcgi://localhost/www/ local [[proxy:debug] [pid 30127:tid 140367020521216] proxy_util.c(1850): AH00930: initialized pool in child 30127 for (localhost) min=0 max=64 smax=64 [proxy_fcgi:debug] [pid 30116:tid 140366778955520] mod_proxy_fcgi.c(73): [client 66.192.178.3:54534] AH01060: set r-filename to proxy:fcgi://localhost:8000/www/index.php [proxy:debug] [pid 30116:tid 140366778955520] mod_proxy.c(1104): [client 66.192.178.3:54534] AH01143: Running scheme fcgi handler (attempt 0) [proxy_fcgi:debug] [pid 30116:tid 140366778955520] mod_proxy_fcgi.c(764): [client 66.192.178.3:54534] AH01076: url: fcgi://localhost:8000/www/index.php proxyname: (null) proxyport: 0 [proxy_fcgi:debug] [pid 30116:tid 140366778955520] mod_proxy_fcgi.c(774): [client 66.192.178.3:54534] AH01078: serving URL //localhost:8000/www/index.php [proxy:debug] [pid 30116:tid 140366778955520] proxy_util.c(2101): AH00942: FCGI: has acquired connection for (*) [proxy:debug] [pid 30116:tid 140366778955520] proxy_util.c(2176): [client 66.192.178.3:54534] AH00944: connecting //localhost:8000/www/index.php to localhost:8000 [proxy:debug] [pid 30116:tid 140366778955520] proxy_util.c(2311): [client 66.192.178.3:54534] AH00947: connected /www/index.php to localhost:8000 [proxy:error] [pid 30116:tid 140366778955520] (111)Connection refused: AH00957: FCGI: attempt to connect to 127.0.0.1:8000 (*) failed [proxy_fcgi:error] [pid 30116:tid 140366778955520] [client 66.192.178.3:54534] AH01079: failed to make connection to backend: localhost [proxy:debug] [pid 30116:tid 140366778955520] proxy_util.c(2139): AH00943: FCGI: has released connection for (*) If I switch from fcgi to http, I get a log that's a bit different and see some lines which lead me to believe the uds is simply lost somewhere in the fcgi setup that it isn't in the http setup (this errors out as the socket is expecting fcgi, not http): ProxyPass / unix:/var/run/php/php-fpm.sock|http://localhost/www/ [proxy:debug] [pid 30707:tid 139930058049280] proxy_util.c(1773): AH00925: initializing worker unix:/var/run/php/php-fpm.sock|http://localhost/www/shared [proxy:debug] [pid 30707:tid 139930058049280] proxy_util.c(1815): AH00927: initializing worker unix:/var/run/php/php-fpm.sock|http://localhost/www/local [proxy:debug] [pid 30707:tid 139930058049280] proxy_util.c(1850): AH00930: initialized pool in child 30707 for (localhost) min=0 max=64 smax=64 [proxy:debug] [pid 30721:tid 139929963685632] mod_proxy.c(1104): [client 66.192.178.3:54544] AH01143: Running scheme http handler (attempt 0) [proxy:debug] [pid 30721:tid 139929963685632] proxy_util.c(2101): AH00942: HTTP: has acquired connection for (localhost) [proxy:debug] [pid 30721:tid 139929963685632] proxy_util.c(2115): AH02545: HTTP: has determined UDS as /var/run/php/php-fpm.sock [proxy:debug] [pid 30721:tid 139929963685632] proxy_util.c(2176): [client 66.192.178.3:54544] AH00944: connecting http://localhost/www/index.php to localhost:80 [proxy:debug] [pid 30721:tid 139929963685632] proxy_util.c(2311): [client 66.192.178.3:54544] AH00947: connected /www/index.php to localhost:80 [proxy:error] [pid 30721:tid 139929963685632] (2)No such file or directory: AH02454: HTTP: attempt to connect to Unix domain socket /var/run/php/php-fpm.sock (localhost) failed [proxy:error] [pid 30721:tid 139929963685632] AH00959: ap_proxy_connect_backend disabling worker for (localhost) for 60s [proxy_http:error] [pid 30721:tid 139929963685632] [client 66.192.178.3:54544] AH01114: HTTP: failed to make connection to backend: localhost [proxy:debug] [pid 30721:tid 139929963685632] proxy_util.c(2139): AH00943: HTTP: has released connection for (localhost) Note in this case the line HTTP: has determined UDS as /var/run/php/php-fpm.sock which is missing from the fcgi case. Digging through the code is proving difficult for me to trace where the path for fcgi breaks down vs http. As an aside, I'm fairly certain that in the case of a fcgi something to the effect of: unix:/var/run/php/php-fpm.sock|fcgi:///www/ ... should be a valid configuration, however this results in the following error: [proxy_fcgi:error] [pid 31259:tid 140608094070528] [client 66.192.178.3:54554] AH01059: error parsing URL //: Invalid host/port
