Comment 3 for bug 888770

@Dustin,

I understand the problem that this MIR is trying to resolve, so a how-to wasn't what I was asking. :)

I was really asking, why run-one is superior to the tools cronutils provide?:

runlock: Prevent concurrent runs of a process.
       runlock tries to hold an exclusive lock while it executes a command.
       Subsequent execution of runlock with the same lock, while that lock is
       held, will cause the new instance of runlock to terminate with a
       faliure exit code. Otherwise, the exit code of the subprocess is
       returned.
http://manpages.ubuntu.com/manpages/precise/en/man1/runlock.1.html

runalarm - enforce a time limit on execution of a process
       runalarm tries to execute a command and, if the subprocess does not
       exit before a timer expires, tries to terminate that subprocess.
       Otherwise, the exit status of the command is returned.
http://manpages.ubuntu.com/manpages/precise/en/man1/runalarm.1.html

Some stat information:
       runstat tries to execute a command in a subprocess, and upon
       termination of the subprocess collects some statics about that
       subrocess, and writes them to a file.

       These statistics include time of execution, exit status, and elapsed
       time to execute, as well as use of various OS resources.
http://manpages.ubuntu.com/manpages/precise/en/man1/runstat.1.html

... The syslog integration seems to fit the Orchestra model quite nicely - particularly posting runalarm warnings.

It *doesn't* have the run-this-one functionality, with runalarm being the nearest option. It seems to me that this is actually a superior suggested workflow of resolving this problem, as I fear people will routinely be happy to essentially "killall foo ; foo" as part of a cron task.

Thoughts?