I've written a patch which allows the use of syslog in nginx.See http://article.gmane.org/gmane.comp.web.nginx.english/5057 Reproducible: Always
Created attachment 153307 [details, diff] nginx syslog support
Created attachment 153311 [details, diff] made use of LOG_CRIT + LOG_NOTICE new patch with different log facilities, instead of logging everything to LOG_CRIT
Created attachment 153345 [details, diff] used format function for syslog() to allow %s, %d, etc in the string
would be cool if Igor could at least make a response there :/
(In reply to comment #4) > would be cool if Igor could at least make a response there :/ > Author of Nginx (Igor) does not like logging to syslog in nginx - see mail archive
I'm trying to write an ebuild that includes this patch with the syslog USE flag, but the patch isn't fully working (about half of the hunks fail) with nginx 0.8.4 Any chance there's an updated patch?
Created attachment 197160 [details, diff] add syslog support to ebuild This patch adds the syslog nginx patch and compiles nginx with syslog support when the syslog USE flag is present.
I'll take a look to make it working against the latest 0.7 and 0.8 branch
Created attachment 197180 [details, diff] syslog patch for nginx 0.8.4 I updated the patch to work with nginx-0.8.4 I've tested this with the ebuild patch attached to this ticket, and it works with my nginx configs, but the patch might be messy (when I tried compiling by hand, it had some warnings), so if someone could check it out, that'd be great.
I'm a bit biased toward third party patching in Nginx. For instance - if this goes through, do we also accept mod_wsgi patches or perhaps passenger? This small and easy to use web server can easily grow into something more complex.
At this time I don't want to increase the maintenance load by pulling in more stuff from outside the distribution, so closing as WONTFIX.
Dirkjan, Can we give some thought to some way to compromise on this a bit and perhaps look at how some extensions could be handled/maintained, even if some bits of that solution remain outside the gentoo tree? I guess you are either an nginx fan or not, but those who are find it an incredibly versatile little tool. It's "weakness" is this requirement to build all extensions at build time I don't have a problem with the extensions living outside of portage, but it would be useful to be able to inject these patches/modules into the normal ebuild without needing to maintain a local customised ebuild everywhere Thoughts on how appreciated...
I appreciate the need for it (in fact, at some point I had an ebuild in my overlay that just added one external module), I'm just not using nginx myself at this point. I just picked it up because it wasn't being maintained, and while bumping it and adding use flags here and there seems straightforward enough, I simply don't have the time to do all kinds of other stuff. I could maybe maintain it as a proxy if there was someone committed who had a clear path forward that started by fixing out all the existing bugs, modularized the current ebuild, and *then* added some external modules...
