# Re: Feature request: Run a script when upstream detected down/up **URL:** \ **Category:** NGINX\ **Created:** [April 29, 2008, 10:51pm UTC](https://www.ruby-forum.com/t/re-feature-request-run-a-script-when-upstream-detected-down-up/136223 "2008-04-29T22:51:26Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Rt\_Ibmer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/59ef9b/32.png) [@Rt\_Ibmer](https://www.ruby-forum.com/u/Rt_Ibmer)\ **Post date:** [April 29, 2008, 10:51pm UTC](https://www.ruby-forum.com/t/re-feature-request-run-a-script-when-upstream-detected-down-up/136223/1 "2008-04-29T22:51:26Z")
> > 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. At a high level, what am I missing / oversimplifying? Perhaps instead, a simpler and more efficient approach may be for me to write to a log when nginx stops routing requests to an upstream box. I cannot use the events it logs current, because it doesn’t differentiate between a failed attempt vs. enough failed attempts based on max\_fails and fail\_timeout. For instance it’ll write to the log saying a connection or timeout occurred with an upstream, but does not record an entry saying that this has occurred max\_fails times and it is now taking that upstream out of rotation for fail\_timeout duration. I think at a minimum even if nothing further is done here it should at least report that event in the logs. Also I may be mistaken but I believe the current logging it does in this regard is only seen with like “notices” - I would expect those to get a high level logging priority like error or critical. > Well, from my point of view your solution is not good engineering and not in the That does not surprise me at all! This is over my head for sure. All I know is that I disparately need to know when nginx stops routing requests to an upstream. And the only way to know 100% sure that its doing so is for nginx to tell us, not to try and determine what nginx must be seeing based on some external monitoring. > I don’t believe Igor is likely to call fork() to execute a script in response to > an event in its code. Agree it is lousy! 🙂 At the same time, for an event that (hopefully) happens very rarely I wouldn’t mind the couple of second hit from inefficiency here. That being said clearly better solutions can be engineered (just not be my unfortunately). > As I’m not a completely negative guy 😉 I propose a more general solution to > monitor Nginx cleanly and to do whatever your want. That is an excellent idea! Basically some sort of event / hook system that nginx can use to report various events (including “upstream down” and “previously detected downed ppstream now back up”). > The script/agent will just read the shared memory and act according to data. Perfect! I just need the hook. Thank you for your consideration and I hope these discussions help make in incredible product even more robust. ``` ____________________________________________________________________________________ ``` Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. [http://mobile.yahoo.com/;\_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ](http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ) ---
**Author:** ![Rt\_Ibmer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/59ef9b/32.png) [@Rt\_Ibmer](https://www.ruby-forum.com/u/Rt_Ibmer)\ **Post date:** [April 29, 2008, 11:37pm UTC](https://www.ruby-forum.com/t/re-feature-request-run-a-script-when-upstream-detected-down-up/136223/2 "2008-04-29T23:37:24Z")
Rt Ibmer \ writes: > > > 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. > > At a high level, what am I missing / oversimplifying? The problem is not at high level but at low level: you cannot put code like this on a server, it’s not a matter of writing two lines but to test potential errors, to have clean configuration parameters and to maintain the software… > Perhaps instead, a simpler and more efficient approach may be for me to write > to a log when nginx stops routing requests to an upstream box. I cannot > use the > events it logs current, because it doesn’t differentiate between a > failed > attempt vs. enough failed attempts based on max\_fails and fail\_timeout. Yes, it could be a solution but not good engineering: log is mostly for post-mortem investigations not for processing live events. It’s dangerous to rely on string patterns. > Perfect! I just need the hook. Some input from the list will be appreciated, I believe that such a module will add value to Nginx but some time is needed in order to fully evaluate the implications and the best implementation. > Thank you for your consideration and I hope these discussions help make in > incredible product even more robust. 😉 ---
**Author:** ![Rt\_Ibmer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/59ef9b/32.png) [@Rt\_Ibmer](https://www.ruby-forum.com/u/Rt_Ibmer)\ **Post date:** [April 29, 2008, 11:46pm UTC](https://www.ruby-forum.com/t/re-feature-request-run-a-script-when-upstream-detected-down-up/136223/3 "2008-04-29T23:46:48Z")
On Die 29.04.2008 21:27, François Battail wrote: > The problem is not at high level but at low level: you cannot put code > like this on a server, it’s not a matter of writing two lines but to > test potential errors, to have clean configuration parameters and to > maintain the software… [snipp] > > Perfect! I just need the hook. > > Some input from the list will be appreciated, I believe that such a > module will add value to Nginx but some time is needed in order to > fully evaluate the implications and the best implementation. I think for this the embedded script language (perl/neko/lua/python/your\_preferd\_lang;-) will be very helpfull 🙂 Brainstorming: 1.) add hook into upstream module, maybe some other modules also 😉 2.) use this hook in $EMBEDDED\_SCRIPT (current only perl) to write into $OUTPUT\_THING (file/shm/…) 3.) use external program which monitor the $OUTPUT\_THING The benefit to use a embedded script language is that the user can write some infos into the output string and some predefined variables from nginx. I know this is a lot of work but it could be a 100% solution 😉 Cheers Aleks ---
**Author:** ![Rt\_Ibmer](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/59ef9b/32.png) [@Rt\_Ibmer](https://www.ruby-forum.com/u/Rt_Ibmer)\ **Post date:** [April 30, 2008, 8:34am UTC](https://www.ruby-forum.com/t/re-feature-request-run-a-script-when-upstream-detected-down-up/136223/4 "2008-04-30T08:34:11Z")
Aleksandar L. \ writes: > I think for this the embedded script language > (perl/neko/lua/python/your\_preferd\_lang will be very helpfull I’m not too sure. If for writing _some bytes_ on memory we need to instantiate an interpretor or a VM and after writing these bytes running a garbage collector, there’s something wrong. > Brainstorming: > > 1.) add hook into upstream module, maybe some other modules also > 2.) use this hook in $EMBEDDED\_SCRIPT (current only perl) to write into > $OUTPUT\_THING (file/shm/…) > 3.) use external program which monitor the $OUTPUT\_THING > > The benefit to use a embedded script language is that the user can write > some infos into the output string and some predefined variables from > nginx. Yes, but it is not the idea. It’s about monitoring indicators like: counters on connections state (same as sub\_status module) upstream servers statuses error counters (like out of fd…) min max avg on resource allocation … That way it will be possible to have useful information for tuning or monitoring servers running Nginx in an efficient way. It’s not designed to help debugging an application. Best regards.