Johannes Sixt <j6t@xxxxxxxx> 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@xxxxxxxx> > --- > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html