Rt Ibmer <rtibmx at ...> writes:
> Thank you. Can you provide a hint as to what .c file(s) I would need to
modify and what types of system calls I should look at? Maybe all I need
to do is find the spot where nginx deems it should skip a downed server,
and immediately after that add this code:
You should look at the file:
nginx/src/http/ngx_http_upstream_round_robin.c
> if (fork() == 0)
> execl("/bin/sh","/path/to/upstream_down.sh","ID of down upsteam
goes here", NULL);
It's not as easy to do.
> Any other considerations I need to worry about?
>> Also if I make this change might it be adopted and incorporated into the
product? I would not want to have to keep applying my own patch every
time I compile a new version of nginx and am happy to contribute my
work to this excellent product and project. Thank you.
Well, from my point of view your solution is not good engineering and not in the
spirit of Nginx. I understand your need but good supervision and monitoring is
what is needed.
I don't believe Igor is likely to call fork() to execute a script in response to
an event in its code.
As I'm not a completely negative guy ;-) I propose a more general solution to
monitor Nginx cleanly and to do whatever your want.
Just need to create a shared memory area named nginx for example and put data as
in the /proc filesystem. It's like stub_status module but using shared memory
instead of HTTP. In the case of upstream servers status writing on shared memory
during a state change (down/up) has no significant cost.
The script/agent will just read the shared memory and act according to data.
The bad thing is that the nagios and collectd plugins will need a rewrite!
I've used this technique on a mission critical application (40 processes, ~ 700
threads) running on an AIX box, it was useful to collect statistics and
benchmark data without stressing the system.
So Dear List, what do you think?