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

[Manlio Perillo]

Cliff Wells ha scritto:
> On Wed, 2008-04-30 at 05:03 -0700, Mansoor Peerbhoy wrote:
>> Manlio,
>>
>> Yes, I see what you're saying. 
>> It is always going to be a problem if the listener cannot consume the
>> data fast enough. 
> 
> I think if Nginx only updated counters (similar to OpenVZ's bean
> counters) this would not be an issue and would work well with the shared
> memory/virtual file approach (and fits better with the idea of event
> monitoring vs logging/post-mortem).  Rather than a stream of data you
> have a "file" of fixed size that's constantly updated. It also
> simplifies the parsing of the data by an external application. 
> 

There is a potential problem with this solution.
To be able to write atomically all this information, Nginx have to use a 
spin lock to lock the memory region.


However the default implementation in Nginx uses an atomical variable 
visible only by Nginx.

This means that an external process have no way to sinchronize memory 
access with Nginx, and it may read inconsistent values.

Moreover if the external process can synchronize with Nginx there is the 
risk that this external process will keep the lock for too much time, 
thus blocking Nginx.


The solution is to only store atomic_t values in the shared memory, so 
that it can atomically updated.

As an example
/tmp/nginx/01
/tmp/nginx/01/address
/tmp/nginx/01/name
/tmp/nginx/01/tries
/tmp/nginx/01/down


where 01 is the upstream peer number, and only the `tries` and `down` 
files will be updated (and they will contain an integer value in binary 
format).


> If a virtual file system (like /proc) were used, then it should also be
> possible to use inotify (or similar) from external apps to be notified
> of events (although this might be too busy).
> 

This should work with a normal filesystem too.

> Regards,
> Cliff
> 
> 
> 



Regards  Manlio Perillo