[RFC] fixing mod_cgid error logging

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC] fixing mod_cgid error logging

Joe Orton
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.

I'm going to run with (2) in two steps unless there are major
objections.

a) make fd passing work (opt-in via configure switch) if ErrorLog is an
fd, by passing that fd directly to the server (fixing PR 60692 only) -
PoC attached to show this is relatively simple, +100 lines

b) then make that work via a new pipe with the CGI bucket abstracted out
and used across both mod_cgi/cgid (properly fixing PR 54211)

Regards, Joe


ap_cgid_fdpass.patch (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] fixing mod_cgid error logging

Stefan Eissing
No objections from me, as I lack the expertise here. Patch looks readable, though. ;)

> Am 05.07.2019 um 12:57 schrieb Joe Orton <[hidden email]>:
>
> 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.
>
> I'm going to run with (2) in two steps unless there are major
> objections.
>
> a) make fd passing work (opt-in via configure switch) if ErrorLog is an
> fd, by passing that fd directly to the server (fixing PR 60692 only) -
> PoC attached to show this is relatively simple, +100 lines
>
> b) then make that work via a new pipe with the CGI bucket abstracted out
> and used across both mod_cgi/cgid (properly fixing PR 54211)
>
> Regards, Joe
>
> <ap_cgid_fdpass.patch>

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] fixing mod_cgid error logging

Ruediger Pluem
In reply to this post by Joe Orton


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

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] fixing mod_cgid error logging

Joe Orton
On Fri, Jul 05, 2019 at 01:39:21PM +0200, Ruediger Pluem wrote:
> 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

Ah, good call, I'd completely forgotten that mod_proxy_fdpass uses
exactly the same technique.  I'm guessing it's not really APR material
since it's a quite Unix-specific.

My two-decade-old copy of Stevens's UNP talks about differences between
4.4BSD and SVR4, but the API appears to be a POSIX standard these days.

Regards, Joe