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

There are no problems at spawing an external process.
Simply, Nginx does not directly support this and you will get a lot of
NOTICE messages in the log when each process exits (even if it exits
with a success status code).

That is fine. Such “upstream server down” events should be rare and the
extra notices in the logs will not impact things.

Personally I’m not interested in this feature, sorry.
I have given a look in the Nginx source code and it seems that all you
want is implementable, and it should require only a few hours of coding.

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:
if (fork() == 0)
execl("/bin/sh","/path/to/upstream_down.sh",“ID of down upsteam goes
here”, NULL);

Or should I be using the system() function?

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.

  ____________________________________________________________________________________

Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Rt Ibmer <[email protected]…> 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 :wink: 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?

François Battail ha scritto:

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?

It seems very interesting and should not be hard to implement.

Regards Manlio P.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs