Re: [PATCH] daemon: send stderr of service programs to the syslog

["Shawn O. Pearce" <spearce@spearce.org>]

Johannes Sixt <j6t@kdbg.org> wrote:
> If git-daemon is run with --detach or --inetd, then stderr is explicitly
> redirected to /dev/null. But notice that the service programs were spawned
> via execl_git_cmd(), in particular, the stderr channel is inherited from
> the daemon. This means that errors that the programs wrote to stderr (for
> example, via die()), went to /dev/null.
> 
> This patch arranges that the daemon does not merely exec the service
> program, but forks it and monitors stderr of the child; it writes the
> errors that it produces to the daemons log via logerror().
> 
> A consequence is that the daemon process remains in memory for the full
> duration of the service program, but this cannot be avoided.
> 
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
>  I don't know whether service programs like upload-archive or upload-pack
>  write progress report to stderr or not, for example, if a client does not
>  support side-bands. In this case this patch is probably not enough since
>  this would fill the log with unneeded progress information. Any hints
>  are appreciated.

They could, if they were broken.  :-)

IIRC only upload-pack produces progress (from pack-objects).
It does so by using a pipe on fd 2, and either copying it down
to the client via side-band, or discarding it.  So progress data
shouldn't ever appear on upload-pack's own fd 2, which means you
won't get it in this syslog thing.

But I have to wonder, why are we doing this?  Why can't we teach the
individual server program to record its error to the syslog before
it aborts?  Are we looking for SIGSEGV or something?  Its only the
daemon program staying around in memory, but that's a lot of little
daemons doing nothing waiting for their children to terminate.
Seems like a waste to me.
 
-- 
Shawn.