nic-6443 opened a new pull request, #14087: URL: https://github.com/apache/apisix/pull/14087
Fixes #12928 `apisix start` launched openresty through `util.execute_cmd()`, which `io.popen()`s the command and reads its stdout until EOF. When `nginx_config.http.access_log` is `/dev/stdout`, nginx opens that path while parsing the config, so the log fd ends up pointing at the popen pipe. The daemonized master and workers keep the write end open, EOF never arrives, the CLI blocks forever and every access log line piles up in its memory until it gets OOM-killed. The output was thrown away anyway — `start` never looked at it. Now `start` runs openresty with `os.execute()`, so openresty just inherits the CLI's stdout/stderr. Error reporting is unchanged: nginx errors still go to stderr as before, and the return value was never checked. `restart` goes through `start`, so it's covered too. The other `execute_cmd` callers (`-s quit`, `-s stop`, `openresty -V`, ...) run short-lived commands that don't keep the pipe, so I left them alone. Behavior change: with an access log on `/dev/stdout`, `apisix start` used to hang forever while silently swallowing the logs. It now returns once nginx has daemonized and the logs go to wherever the caller's stdout points. A container whose only command is `apisix start` was relying on that accidental blocking and will now exit; it should use `apisix docker-start` (or run openresty with `daemon off;`) as the official image does. Added a case to `t/cli/test_access_log.sh`: with `access_log: /dev/stdout`, `apisix start > file` must return within 30s, and after a request the access log line must show up in that file. It times out without this fix. -- 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]
