Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Actually I'm not so sure whether i should use Shell Scripts, or if there some ways already. But whatever approach we use, i would like to keep a Service running all the time.

Let's say iptables as an example. Then ..

  • Whenever the iptables service is stopped or (in other words) not running, i want it to be started (or restarted) .. automatically whenever it stopped (or not running).
  • In other more simple words, i want to keep a Service up and running all the time.

(May be i could give a fair frequency to check, if doing Real-time checking is the problem. So lets say, every 5 mins)

The only way i could think of, is to use Shell Scripts with Cron Tab.

  • Is there any smart solution please?


share|improve this question
You should not do that. Suppose a service is ill-configured, what would your strategy achieve? An infinite list of retrials. You should instead write a crontab script that alerts you to something not working. – MariusMatutiae Dec 3 '13 at 9:12
I'm just curious about the straight solution, for the original question. And also, i have a Service which just needs to be simply restarted whenever it stopped, for any reason. No problem with restarting. – 夏期劇場 Dec 3 '13 at 9:43
Your own suggested solution is smart enough. If you use it correctly (exit immediately if service is already running, alert you that the service has stopped so you can fix it, and so on....) it is the simplest way. A service that stops automatically is a problematic service, so eventually you should fix it, but otherwise, as a temporary patch, a cron script or another super-simple daemon that sleeps most of the time will do the job just fine. There are some tools like but I think that in the end they all use a similar approach – user268693 Dec 3 '13 at 10:40
@MariusMatutiae, I agree with your point but it depends on the nature of the service, and most process managers will back off after a number of failed restarts. It's perfectly reasonable for a process to naturally end, and for us to want to restart it automatically, e.g. a worker that picks up a job from a queue and ends after each run. It's also a handy tool for sysadmins that suffer from bespoke memory-leaking code - limit the lifetime of a process and restart it automatically before it can get out of hand... – Alex Forbes Dec 11 '13 at 23:50

The monit answer above is valid, but I thought I'd mention some alternatives:

It's worth bearing in mind that your operating system has already solved the process management problem. Traditionally, Linux has used sysvinit, which is basically the collection of scripts you see in init.d. However it's pretty dumb and can not monitor processes, init.d scripts are complicated and it's being replaced for good reason.

More modern operating systems are starting to replace sysvinit, and the frontrunners are Upstart and Systemd. Debian is leaning towards systemd, Ubuntu developed and has pretty much already transitioned to Upstart, and like Debian Redhat/CentOS/Fedora are moving towards systemd. Thus if you use an OS that has already replaced sysvinit I would recommend using what's built-in. The scripts are much easier to write than init scripts.

I have used runit and quite like it, but the easiest to use is supervisor. It's also very well documented, works almost anywhere and is packaged in all the major distributions.

But whatever you do, please, please, PLEASE do not use a shell script. There are so many things wrong with that approach!

share|improve this answer
Upstart is terrible for monitoring complex services. Try this: setup an Upstart script to start a Unicorn server. Make sure add "respawn" in there. Now kill the process. Upstart does nothing and you can't even manually restart the service because Upstart is confused about the state. – Mike Bethany Jun 23 '15 at 19:54

iptables is a poor example as it's not really a service or daemon that is running, but part of the kernel. You can't really "stop" iptables, you can only give it a configuration and "stopping" it involves giving it a blank configuration. Indeed I have had Linux systems crash, but the port forwarding setup using iptables continues to work.

Anyway, a utility called monit will do what you want. If you are using Debian it's an apt-get install monit away. It's a bit involved to learn about but very flexible.

share|improve this answer
Thanks for help. Monit is a very useful program. Is monit successor of Mon? – Pol Hallen Jun 12 '14 at 21:33
I don't believe they are related. :) – LawrenceC Jun 12 '14 at 21:41

We are using this simple script to make an alert and start the service if it is not running, You can add more services too..

 file name:

 #service monitoring
 /bin/netstat -tulpn | awk '{print $4}' | awk -F: '{print $4}' | grep ^80$ > /dev/null   2>/dev/null
 a=$(echo $?)
 if test $a -ne 0
 echo "http service down" | mail -s "HTTP Service DOWN and restarted now" root@localhost
 /etc/init.d/httpd start > /dev/null 2>/dev/null
 sleep 0
 /bin/netstat -tulpn | awk '{print $4}' | awk -F: '{print $4}' | grep ^53$ > /dev/null   2>/dev/null
 b=$(echo $?)
 if test $b -ne 0
 echo "named service down" | mail -s "DNS Service DOWN and restarted now" root@localhost
 /etc/init.d/named start > /dev/null 2>/dev/null
 sleep 0

 Cron setup:
 */5 * * * * /root/ > /dev/null 2>/dev/null
share|improve this answer
MariusMatutiae's point is correct but we have done a simple script to monitor the HTTPD and DNS service in my server, its running fine. When ever the service is down the script will restart the service and make an alert to us, It we get plenty of alert / mails regarding the service down, then we can do an investigation on it. – Ranjithkumar T Dec 8 '13 at 5:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.