On 07/05/2019 12:57 PM, Joe Orton wrote:
> PR 54211 and 60692 track a design problem in mod_cgid: the stderr of
> spawned CGI scripts is a copy of the main server's stderr. This is a
> significant regression from mod_cgi (you lose logging prefixes,
> per-vhost config, non-file/pipe-logging provider support e.g. syslog)
>
> I can think of two main approaches to fix this:
>
> 1) enhance the client/server protocol which cgid uses to be a bit more
> like FastCGI with headers, record types, etc and multiplex both stderr
> and stdout over the Unix socket. We'd need a new thread or process for
> each new spawned script child to translate CGI stdout/stderr into this
> protocol, or to completely redesign the cgid_server main loop to be
> event-driven. Plus a new bucket type similar to the CGI bucket which
> handles the protocol client side.
>
> 2) Create a new pipe for stderr in the client and pass this to the
> server using Unix fd passing magic for the CGI script to use as stderr.
> Factor out the CGI bucket from mod_cgi and use this as-is in mod_cgid.
>
> I think (1) might be a cleaner design in the long run but (2) is going
> to be vastly simpler to implement. (2) might take some effort from
> platform maintainers to work across all Unixes.
How much portable is this and do we have / should have something in APR that
does that portability?
We probably should guard this with a check for
#ifndef CMSG_DATA
#error This module only works on unix platforms with the correct OS support
#endif
like we do for mod_proxy_fdpass:
APACHE_MODULE(proxy_fdpass, Apache proxy to Unix Daemon Socket module.
Requires --enable-proxy., $proxy_fdpass_objs, ,
most, [
AC_CHECK_DECL(CMSG_DATA,,, [
#include <sys/types.h>
#include <sys/socket.h>
])
if test $ac_cv_have_decl_CMSG_DATA = "no"; then
AC_MSG_WARN([Your system does not support CMSG_DATA.])
enable_proxy_fdpass=no
fi
],proxy)
Regards
Rüdiger
