1

I've got a CentOS 5.11 box that I have to work with for now--in a production env where I can't really push it to CentOS 6, at least for awhile. I have to be low-impact on this project, can't mess up this production box.

I have a script, call it /my/foo. Right now, that script runs from cron every 3 minutes--it actually runs as:

*/3 * * * * /my/foo myparam

Problem is, the script typically only takes a few seconds to run, then we waste almost 3 minutes waiting. But, we can ONLY have one instance running at a time (so actually we already have a vulnerability if an anomaly causes a longer-than-3-min run). Occasionally the script might have a lot of stuff to do and take 2 mins, thus we have it set at 3 or so.

What we're really shooting for is to simply guarantee that one, and only one, instance of this script runs "indefinitely" (looping) and, most likely, we'll pop a "sleep 30" in there just to keep it from being too aggressive. The script itself is not a loop--it's a one-pass script. But we definitely waste a lot of time in 99% of circumstances by only running it every 3 mins from cron. The 1% of cases where it takes >2 mins means we spend 99% of cases waiting around when it could run again and get more work done.

So we figure it might a decent hack to, for now, put it into the init system with a respawn. There, it runs, finishes, respawns (prob with that little sleep in the script itself). Forever. This is resilient (an accidental kill of the process doesn't mean it's dead forever, etc.).

I've seen a lot of posts about about upstart, even some debate about its future in CentOS 6, and so on. But again, I have to pop this onto this CentOS 5 box for now--we don't have upstart and won't have it soon. I have to slide this onto this production box with what I've got...and without breaking anything.

I've seen /etc/inittab kinda poo poo'd, but it's also been noted that that's the best way to get respawn--that /etc/init.d/whatever linking to /etc/rc3.d/whatever and so on, the typical way, doesn't give respawn capabilities. I'm still not sure about that--seems that way.

Given these constraints, is it best, and reasonable, to pop our little script into /etc/inittab itself with a respawn and go?

Dan
  • 61
  • 2

1 Answers1

0

I would daemonize the script/process and manage it with Monit.

This would give you respawn and process control, but also allow you to run/check the process on a shorter interval than cron (e.g. 15 seconds)

ewwhite
  • 194,921
  • 91
  • 434
  • 799
  • Thanks. What advantage does going through the effort of "daemonizing" the script, installing and configuring (and learning) Monit, and controlling it thereby, give over using inittab? If inittab will do the trick fine (as we are thinking, respawn + short interval) then I want to understand what big advantage pursuit of Monit gives. – Dan Aug 24 '15 at 18:07
  • Monit is simple to understand and more elegant than putting scripts in `/etc/inittab`. – ewwhite Aug 24 '15 at 18:10