Opened 6 years ago

Closed 3 years ago

#95 closed enhancement (wontfix)

Integrate syslog patch into modules

Reported by: tessarji@… Owned by: somebody
Priority: minor Milestone:
Component: nginx-module Version: 1.0.x
Keywords: Cc:
Sensitive: no
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?

https://github.com/yaoweibin/nginx_syslog_patch

Change History (7)

comment:1 Changed 6 years ago by mdounin

  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:2 Changed 5 years ago by josephholsten.com

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 Changed 4 years ago by www.google.com/accounts/o8/id?id=AItOawnUGSYXsruhpsDRmWVgJ3WQeiYuwNIfyd0

+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 Changed 4 years ago by www.google.com/accounts/o8/id?id=AItOawnUGSYXsruhpsDRmWVgJ3WQeiYuwNIfyd0

  • Resolution wontfix deleted
  • Status changed from closed to reopened

comment:5 Changed 4 years ago by www.google.com/accounts/o8/id?id=AItOawnUGSYXsruhpsDRmWVgJ3WQeiYuwNIfyd0

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 Changed 4 years ago by www.google.com/accounts/o8/id?id=AItOawnoIZPNlDiAQt3HD_yTO6DKySf_R-cXhQk

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 Changed 3 years ago by vl

  • Resolution set to wontfix
  • Sensitive unset
  • Status changed from reopened to closed

These patches are no longer needed. See http://trac.nginx.org/nginx/ticket/409.

Note: See TracTickets for help on using tickets.