tuhaihe opened a new pull request, #149: URL: https://github.com/apache/cloudberry-pxf/pull/149
closes: #148 --- ## Change logs `pxf start` can retry until it gives up while the PXF service is actually up and healthy. The readiness probe in `server/pxf-service/src/scripts/pxf` is: ```bash until $curl --silent --connect-timeout 1 -I "http://localhost:$PXF_PORT"; | grep 'PXF Server' > /dev/null; do ``` `curl` does not automatically bypass proxies for `localhost`. On a host where `http_proxy` is set — common when a proxy is needed to fetch build dependencies — this probe is sent to the proxy, which cannot reach the loopback interface of the PXF host and answers `502 Bad Gateway`. `grep 'PXF Server'` never matches, so `pxf start` keeps retrying for the full 300 attempts (`checkWebapp 300 10`), and `pxf status` reports `ERROR: PXF is down` for the same reason. This PR passes `--noproxy '*'` to the three `curl` invocations in the script. All three target endpoints that are by definition local to the host, so they should never be routed through a proxy: 1. the readiness probe in `waitForSpringBoot` 2. the `/actuator/health` check in `checkWebapp` 3. the `/actuator/shutdown` call in `doStop` — this one fails silently with a proxy set as well, so `pxf stop` currently falls back to `SIGTERM`/`SIGKILL` instead of shutting down gracefully ### Reproduction ``` $ export http_proxy=http://proxy.internal.example:1080 $ pxf start Checking if PXF is up and running... PXF not responding, re-trying after 1 second (attempt number 10) ... ``` Meanwhile the service is running and listening: ``` $ ss -lntp | grep 5888 LISTEN 0 100 [::ffff:127.0.0.1]:5888 *:* users:(("java",pid=111698,fd=11)) $ curl -sS --noproxy '*' -D - -o /dev/null http://127.0.0.1:5888 HTTP/1.1 404 Content-Type: application/json Server: PXF Server ``` ### Verification - `bash -n server/pxf-service/src/scripts/pxf` passes. - Confirmed the array expands to exactly `--noproxy` `*` with no literal quoting and no glob expansion, and that the flag takes effect: with `http_proxy` pointing at a dead proxy, `curl "${curl_opts[@]}" -I http://localhost:1` exits `7` (direct connection refused) rather than `5` (could not resolve proxy). - `pxf start` / `pxf status` succeed on a Rocky 9 + Java 17 host that has `http_proxy` set and no `no_proxy`, where they previously failed. Setting `no_proxy` works around the problem, but the local management endpoints should not depend on the ambient proxy configuration at all. ### Note for anyone debugging this `$PXF_BASE/logs/pxf-app.out` contains only the Spring Boot banner, which looks like an aborted startup but is expected: the root logger in `pxf-log4j2.xml` only has the `RollingFile` appender, so the startup log goes to `pxf-service.log`. The retry message is also identical for "not up yet", "failed to start" and "cannot be reached", which makes this class of problem harder to diagnose than it needs to be. Happy to follow up separately on distinguishing those cases. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
