Automagically restart httpd without your intervention!

[skavoovie]

Well, it just demonstrates the beauty of coding and Linux...there are 1,000 ways to do just about anything and everything.

I think it's obvious Mike wasn't trying to provide a full-blown SERVICE level monitoring, but rather, a quick, efficient, simple way to monitor SYSTEM level, with little to no overhead.

The script definitely accomplishes that, and based upon my very extensive experience in large-scale production-level monitoring, suspect it will catch better than 70-80% of outages.

[jasonaward]

In large scale production level monitoring is 70-80% acceptable?

I'm simply pointing out that there are some holes in this method. Anyone using it should be aware of those holes.

Honestly, I think this method would work nearly as well:

#!/bin/bash

 wget -q -O - http://127.0.0.1/monitor.php | grep -q "OK"
[ $? == 0 ] || HTTPTest="80 "

if [ "$HTTPTest" ]; then
   echo "`date '+%F %T'`   Port(s) ${HTTPTest} unbound!"
   #do some good stuff
fi

And great performance too!

serv012 ~ # time ./test.bash

real    0m0.014s
user    0m0.000s
sys     0m0.000s

[skavoovie]

I laugh at the thought that anything having to do with any type of 3rd party VPS could even remotely be considered anything resembling large scale. I would consider large scale to involve an annual budget of no less than, say, $2-5 million. So, that's not even applicable to my original point. However, I can tell you that in a large scale production environment, yes, simple port tests often catch 70-80% of the issues quicker than service-level monitoring. The remaining 20-30% involve outages other than hard system/service failures, detectable only by service-level monitoring. And system resource monitoring would preempt them all, with advanced notice prior to an actual outage.

Using wget hadn't even crossed my mind -- the benefits of the scope of what can be tested, especially by dynamically generated content -- far outweigh any increase in load.

And yeah -- swapping out wget for a either a static page or a dynamic page generating specific content would definitely be better -- much agreed. Certainly cheaper ($ and cycles) than a complete monitoring app.

[jasonaward]

Originally Posted by skavoovie

I laugh at the thought that anything having to do with any type of 3rd party VPS could even remotely be considered anything resembling large scale.

Never once did I say that. You simply said that in a "large-scale production-level monitoring, suspect it will catch better than 70-80% of outages."

My point was that I doubt in any large scale environment you would be using said script if it could only provide you with only 70-80% effectiveness.

[bfp]

Or switch across to the Litespeed web server to do your http

Litespeed auto-restarts itself without the need for futzing around with external scripts:
http://www.litespeedtech.com/docs/we...l/#autoRestart

[Peter]

Hi.. Please somebody can help me about this script...
We try this "autorestart" on my crontab, but it doesn't work..

I have a VPS on Verio.

My bashfile is named: monit_httpd.sh
this file created by root user and we add exe. right (chmod +x)

------------------------------------------------------------------------
#!/bin/bash

LOGFILE="/monitoring/log/autorestarts.log"

# HTTPd Test
netstat -ln | grep -q ":80 "
[ $? == 0 ] || HTTPTest="http "

if [ "$HTTPTest" ]; then
echo "`date '+%F %T'` Port(s) $HTTPTest unbound!" >> $LOGFILE
restart_apache > /dev/null 2>&1
[ $? == 0 ] && echo "`date '+%F %T'` HTTPd restarted successfully." >> $LOGFILE || echo "`date '+%F %T'` PANIC: Unable to restart HTTPd. Service is still down." >> $LOGFILE
fi
------------------------------------------------------------------------

.. I can't use other command then "restart_apache"because verio use this command...

i tweak the bashfile to test purpose

i change the line: netstat -ln | grep -q ":80 "
to: netstat -ln | grep -q ":84 "

i execute the bash:
[root@monitoring]# sh monit_httpd.sh

the system return "Syntax OK" and All work perfect..

and the log are writting and apache restart.. everyting is good..


BUT .. when i tried in crontab, the system return this error:

Subject: Cron <root@admin> /monitoring/monit_httpd.sh
Content-Type: text/plain; charset=ANSI_X3.4-1968
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>

/bin/sh: /monitoring/monit_httpd.sh: Permission denied


??? help me !..

[DanL@VPSLink]

Any advice I can offer is going to be very general, and not necessarily correct (given that I haven't had an opportunity to explore the idiosyncrasies of a default VPS configuration at Verio) - but here are some tips:

1) Double-check cron's usergroup to ensure that it has the right permissions to run the file - this seems to be the most likely cause of the issue (you could experiment with this very quickly by chmod 777'ing your /monitoring/ directory and files - it is also possible that cron is having trouble writing to the /monitoring/logs/ directory)

2) If the issue persists, try using the full path for all commands

3) If further troubleshooting and investigation do not resolve the issue, consider VPS hosting at VPSLink - we'll be able to provide you with more accurate information...

... and we promise not to jail your cron process and forget to tell you about it

@Peter: What does your cron look like? And did you set your cron up with crontab -e as root? Or some other way?

[nura235]

Go to the last line, and add this:

0-59/1 * * * * /root/automagic.sh

Where to add the above quote line.

it should be add in touch.automagic.sh

and 1 more question the above command will work on centos i m using hypervm and kloxo admin and how can cron know that which file to execute.

any help will appreciate

[davepusey]

I use a combination of monit and serviceuptime.com

Monit will attempt to restart my daemons, and if that fails or the site is down for some other reason, i get email and sms alerts from serviceuptime.com