[tptacek]

I'm surprised there aren't more things like this, because Cron replacements are really valuable.

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.

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.

[minimax]

I don't think it's uncommon at all to roll your own job scheduler. I know I've done it at the last two places I have worked, though neither had nearly as fancy a front-end as Chronos appears to have. This particular scheduler (Chronos) looks like a cross between traditional cron and HPC cluster job scheduling systems (a la Sun Grid Engine). It looks like a really cool project.

[tptacek]

That depends on what you mean by job scheduling, right? Lots of people would call Resque a job scheduling system, but they still reach for cron when they want to run something every 5 minutes.

[minimax]

I'm about as unaware of the Ruby ecosystem as anyone who regularly reads HN can be, so while I've heard of Resque I'm not really sure where it fits in.

I suppose the definition of job scheduling is dependent on what your workload entails. Is it something you expect to complete in less than a second, a minute, or a big resource intensive HPC job you expect to run for hours? What sorts of dependencies do you have between the things you want to run? Will it run in the main event loop, separate thread, separate process, or on a separate host? I think this will reflect in the tool you choose for scheduling, or cause you to write your own.

It sounds to me like the target workload for Chronos is big slow batch jobs (ETL, data analysis). HPC job schedulers take care of things like resource management (run this job on this machine because it has the lowest load) and dependency management (don't run job b until job a completes), whereas cron handles running periodic tasks and that's about it. Chronos is nice because it looks like it is combining the two and includes a nice looking web based control panel to boot.

[jeremyw]

I'll mention solving a lateral problem. We liked crond fine, but wanted a minimal impact way to make crons to survive machine stalls, they needed to consistently run somewhere.

So a small bit of Python is enough to perform ephemeral leader election -- for the current minute -- in Zookeeper. Prefixed to otherwise stock invocations a set of machines run the same thing, one of them wins, nobody gets paged.

  * * * * * my long and winding command
  [becomes]
  * * * * * cron-coord somename my long and winding command

[recuter]

> 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.

That's actually pretty interesting. Can you give a few examples that fall out of having a more fine grained (millisecond) resolution?

[tptacek]

One example that jumps to mind was that I was able to rip out several hundred lines of fiddley retry and backoff code and replace it with fine-grain-timed repeating events.

One advantage to doing this in Redis was that our events aren't just "run a program" (though we can do that); we can also push onto a queue that consumers BLPOP from, or send a pubsub message to a bunch of consumers, or increment counters.

later

Makes you think, it's nice that Redis is minimal, but a core feature that might work really nicely with Redis is timer support.

[thezilch]

You will get said timer support in Redis 2.8 with the ability to subscribe to keyspace events, which includes keys expiring (with millisecond resolution). https://github.com/antirez/redis/issues/594

  psubscribe __keyevent@0__:expired cron_*

  psetex cron_run-me-in-1s 1000 0

[kelnos]

It's not clear to me from the writeup if you'll get notification when the key actually expires, or when the key is expired because someone tried to access it.

Currently keys don't actually really expire from the datastore until someone tries to access it after its TTL runs out. Changing redis so it will actually actively expire keys at the precise time the TTL runs down sounds expensive... but I would love that feature nonetheless.

[thezilch]

Redis's expirey strategy has changed as of Redis 2.6, which does have Redis actively expiring keys.

[kelnos]

Ah! I did not know this! This may make a few things simpler for me...

[jeromeparadis]

Awesome! I've been waiting for this for a while.

[codewright]

Don't suppose you could be convinced to release that scheduling daemon as open source, could you?

[tptacek]

Seems like it's all downside and not much upside; it's an unambitious little C project that would mostly give people an opportunity to write blog posts about my C programming style. :)

I'm not saying I'll never publish code, just that I've become choosy about it in my advancing years.

[sillysaurus]

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.

Please open source this. Projects like these are some of the most valuable ones. It's a generalized solution to a very common problem. In fact, what you've described is one of the most elegant designs for this type of problem. It enables any program to schedule other programs just by using a standard Redis interface, for example. Almost every programming language already has a Redis library, meaning it's effectively zero additional work to use your system. Something like your project is sorely needed.

If you want help with documentation, I'm happy to offer it.

Seems like it's all downside and not much upside; it's an unambitious little C project that would mostly give people an opportunity to write blog posts about my C programming style. :)

So was Unix, originally. Those who would deride elegant design due to the choice of language are both short-sighted and mean, and aren't worth worrying about. I know how hard that can be to deal with -- people's negativity tends to bother me a lot, too -- but the world needs more production-grade solutions to real problems. It sounds like your solution has been in use for some time now, and has proven itself effective in the field.

[tptacek]

ok ok ok ok but I'm going to do it pseudonymously :).

[codewright]

My C is terrible, probably far worse than you perceive yours to be.

I'm sorry you feel that way. I hope you change your mind, advancing years or no.

I'm with Sillysaurus, this is a great solution to a common problem.

Pawn off the code onto me and I'll publish it under my name if you're that worried about getting bad publicity. :P

[tptacek]

I actually feel very good about my C code; C is my native language. I just feel very bad about the Internet. :)

[Surio]

>> I actually feel very good about my C code [....] I just feel very bad about the Internet. :)

I laughed first, then realised there is more than a ring of truth to that line :/

If you do release (pseudonymously or otherwise), then release it and please announce to those of us, who are all genuinely interested in it in the first place :)

[codewright]

Then ignore them and please publish.

[thezilch]

We've utilized a similar setup using https://github.com/benliles/TxScheduling (Python, Twisted Scheduling) backed by a DB store.