Feature request: Run a script when upstream detected down/up

Manlio Perillo manlio_perillo at libero.it
Wed Apr 30 13:37:07 MSD 2008

Mansoor Peerbhoy ha scritto:
> hello,
> i have a small suggestion to make (slightly off topic):
> i think this problem would be best solvable by having nginx capable of logging to a file-type other than a regular file.
> for instance, if the nginx error_log directive (http://wiki.codemongers.com/NginxMainModule#error_log) could support a TCP/IP or a unix domain socket or a named pipe, then interesting programs can be written around it which may be an easy approach:
> a) for instance, having an external program monitor nginx logs for a particular log message (or "event"), is not so easy when the file in question is a regular file. the reason for that is, regular files are *always* ready to read on linux (even if the FD is at EOF), so you can't use an open file descriptor to a regular file in a select()/poll() system call and expect it to work the way you want. (i.e. ready-to-read)
> it could be done (tail -f does that), but it's rather messy to have a file-change notification, plus seeking to the appropriate offset. -- with sockets/fifos, these problems can go away. you can set up a socket server to listen on the given socket for connections, and when nginx starts up, the error log initialization code can connect to the tcp or unix domain socket or fifo in question, and then all calls to nginx_log_* will naturally be written to the socket, instead of written to a regular file

This is not as easy as it seems.
First of all with the current architecture of Nginx, writing to the 
error log is assumed to be synchronous.

This means that if you want to send log messages to a TCP server the 
performance will be bad.

You can use an UDP connection, but what happens if Nginx sends data more 
quickly then the server is able to read?
UDP has no flow control.

 > [...]

Regards  Manlio Perillo

More information about the nginx mailing list