Opened 13 years ago
Closed 11 years ago
#95 closed enhancement (wontfix)
Integrate syslog patch into modules
| Reported by: | Nathaniel Anagnostou | Owned by: | somebody |
|---|---|---|---|
| Priority: | minor | Milestone: | |
| Component: | nginx-module | Version: | 1.0.x |
| Keywords: | Cc: | ||
| uname -a: | Linux localhost 2.6.18-164.el5xen #1 SMP Thu Sep 3 04:03:03 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux | ||
| nginx -V: |
nginx version: nginx/0.8.54
built by gcc 4.1.1 20070105 (Red Hat 4.1.1-52) configure arguments: --prefix=/usr/local/websites/nginx --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_stub_status_module --with-http_perl_module --with-http_geoip_module --with-debug --with-perl=/usr/bin/perl --user=nginx --group=nginx |
||
Description
Third party author created a syslog support patch (based on the original one from 0.5)
Is it possible to integrate this or similar patch into the main branch?
Change History (7)
comment:1 by , 13 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
comment:2 by , 12 years ago
syslog(3) blocking is no excuse. If /dev/log gets full, you've got a lot larger problems than keeping nginx up. Your entire system depends on syslog(3) remaining available, you won't even be able to login.
If you honestly believe a syslog should be non-blocking, you should be advocating that to the glibc project. If not, you are asserting that nginx should remain 'responsive' on a machine that will not allow it to remain so.
comment:3 by , 11 years ago
+1 for syslog support in nginx.
Its worth pointing out that if you are doing blocking non-network IO calls with a networking application like nginx you are probably doing it wrong. Log writing should go to a thread safe queue and processed in another thread.
Asynchronous and buffered logging is fairly standard pattern for high traffic applications.
comment:4 by , 11 years ago
| Resolution: | wontfix |
|---|---|
| Status: | closed → reopened |
comment:5 by , 11 years ago
not meaning to troll, but I'd like to see some more debate on whether this is a good feature for nginx. nginx is fantastic deserving project methinks.
comment:6 by , 11 years ago
A separate thread would work, although appending items to the queue would need to guarantee to be non-blocking (discarding log messages rather than blocking once it's full). Any mutex-based approach would need to be handled very carefully, although a suitable lock-free queue would be ideal - I'm not sure whether there are any really portable lock-free queue implementations around, however.
Actually a simple pipe would probably suffice for any POSIX system as a write() of under PIPE_BUF is guaranteed to be atomic, and the lowest value for PIPE_BUF I've ever encountered is 4KB, which should be plenty for a single log message.
Of course, the printf()-like nature of syslog() might make the queue a little tricky unless you constrained it to pass only simple strings, requiring the caller to marshal up the string with snprintf() or similar first. This could easily be encapsulated into a simple wrapper, however.
comment:7 by , 11 years ago
| Resolution: | → wontfix |
|---|---|
| sensitive: | → 0 |
| Status: | reopened → closed |
These patches are no longer needed. See http://trac.nginx.org/nginx/ticket/409.
There are no plans to. The reason why syslog support isn't available and not considered to be added is simple: syslog(3) blocks if syslogd can't cope with load or dies.