I'm surprised there aren't more things like this, because Cron replacements are really valuable.<p>We wrote a small C program that serves as a scheduling daemon with Redis; we have a keyspace in Redis that can be used to schedule millisecond-granular periodic or one-shot tasks with a flexible "Chronic"-like specification syntax.<p>It is hugely more convenient and usable than cron. Once you have it, you immediately spot lots of opportunities to factor systems into scheduled jobs that you might have avoided doing if it meant you had to deal with cron.
so... cron's a 200kb self contained C program, super simple, does one thing, and does it well.<p>Chronos is built on top of frameworks, needs a few services to run.<p>Certainly it has value, but marketing it as a cron replacement is wrong imo. Chronos is one of these "web-server-service-tool" thingie, but no, it's not cron.
This is almost like saying "A Replacement for Gravity".<p>The benefit having something so simple and singular in function with no dependencies is that there's so little to break. While I appreciate the need for having something with more capability, calling it a "replacement" is a bit facetious.<p>I wish them success and call it an airplane. I'll stick to my hang glider.
Interesting to see that this was built on top of Apache Mesos, a dynamic cluster partitioning framework started by some researchers at Berkeley [1]. So far I've heard about Twitter (and now Airbnb) using Mesos in production. Is anyone else evaluating or using it currently?<p>[1] - <a href="http://incubator.apache.org/mesos/papers/nsdi_mesos.pdf" rel="nofollow">http://incubator.apache.org/mesos/papers/nsdi_mesos.pdf</a>
This is brilliant! I've had to do a lot of work creating queue based systems in recent years, and i really like off the shelf solutions to problems like this. Cron is a great tool, but its a mess once you have a bunch of machines and it really just does not scale.
I really hope someone will succeed in rolling out a good and eventually popular replacement for Cron, because Cron completely sucks.<p>The crontab file has a weird syntax, that in some respects seems to look like a shell script, but isn't really one and some shell constructs work, other not. There are lots of ways you can make a mistake in writing the commands to be executed in a way that the command you intended won't run but will fail silently and you won't get any trace of an error happening. It is hard to even extract some common parts of commands and put them into a variable. I wasted hours and hours debugging weird cron errors. One case was where the crontab of one of the users was moved over to be the system crontab and strangely didn't work. Well, turns out the system wide crontab has one more field, but cron will not signal an error even in an obvious case like this, it will just fail silently (and this is the thing cron is really good at in my experience).
I know a couple guys that will be rather unhappy about the choice of moniker. <a href="http://www.getchronos.com/" rel="nofollow">http://www.getchronos.com/</a>
Tools like this can make a lot of ops housekeeping stuff easier, like log roll ups and deleting old backups and so forth. One doesn't want to depend on particular machines being up; but on the other hand, there's not a 99.999999% uptime requirement.
Always happy to see more tools like this - the bigger the toolbox, the easier our lives are.<p>Of the various approaches I've had to depend on in recent memory, from perl scripts querying a central Db right through to eye wateringly expensive Control-M or Autosys in larger envs, It's plain old cron, fronted by config management (cfengine, puppet, chef, salt - it doesn't matter which) that has proven most dependable, easiest to train others on and simplest to debug.
We've built Luigi at Spotify to solve a lot of similar problems: <a href="https://github.com/spotify/luigi" rel="nofollow">https://github.com/spotify/luigi</a><p>Might be worth checking out if you are building large data flows. We probably run 10k Luigi "tasks" every day, of which the majority is Hadoop jobs. They are all organized in a large dependency graph expressed within Python, and you also get visualization, exception handling, atomic file operation, etc.
Many people do much of the fancy stuff with system managment products (Tivoli or BMC patrol spring to mind from past experiences). With that they can do centralised monitoring of the server and services and software and automate responses to defined conditions allowing automatic responses with the right thought and alerting callout when exceptions to the rules occur and when things need looking at.<p>Now all that said, I'm not uptodate on that side of things and even less uptodate on open source alternative, though my quick look at this does indicate that it is a start in the right directon and can only get better. So quick look and glance over gave me a good gut feeling, which is always nice to have.
Anyone know why launchd hasn't taken off in this regard? I've used it on my personal systems with success, but rarely (if ever) see it mentioned as a cron replacement. Instead, you frequently see these solutions done from scratch.
Im not sure what mesos brings to the table (possibly distributed dependency management), but for a powerful replacement for cron with dependency management, logging, etc. one could use systemd timers [1]<p>1. <a href="http://jason.the-graham.com/2013/03/06/how-to-use-systemd-timers/" rel="nofollow">http://jason.the-graham.com/2013/03/06/how-to-use-systemd-ti...</a>
I was planning to do something similar after I learned about Mesos although I haven't found the time. At the moment I'm using a few processes with MySQL publishing with RabbitMQ to handle distribution and node failures. It doesn't have nearly as nice an interface but RabbitMQ isn't terribly difficult to manage. Thanks for open sourcing!
As far as Cron replacements go, I prefer whenjobs [1].<p>[1] <a href="http://people.redhat.com/~rjones/whenjobs/" rel="nofollow">http://people.redhat.com/~rjones/whenjobs/</a>