Jobber: A replacement for cron, with status-reporting and error-handling | Hacker News Reader

Jobber: A replacement for cron, with status-reporting and error-handling

dshearer.github.io

35 pointsdshearer22 comments

https://github.com/dshearer/jobber/blob/master/jobber/jobber...

No thanks.

Yeah, I'm with you on that TBH. There's nothing like a good bit of condescension from a developer to really win over their users. It was sad a few decades ago, and it's still sad now.

Meh. If this was indicative of anything other than somebody wanting to have a bit of fun when typing error messages, you might be on to something.

I don't mind a bit of humanity in my soul-less machines

Think of it as a message from the writer to the user.

I am thinking of it as a message from the writer to the user, and doing so gives me a little chuckle as I remember there is a human on the other side of the code that makes my server run.

It's funny, the first time, maybe. But if you use software all the time then such 'funnyness' becomes irritating. I'm trying to imagine working hard on trying to solve some issue for someone, mistyping a command and getting crap like that thrown back at me. Imagine all your software would return its errors laced with profanity.

If you write code for yourself then that's one thing, as soon as you write code for potential distribution to a large audience (cron is present on just about any unix machine) then I think you should restrain yourself from trying to be funny (or at a minimum from having your software by proxy call people names).

Call me old fashioned, it just doesn't work for me.

(Jobber author here.) It's...interesting that this is the aspect that has gotten the most discussion so far. But thank you, jacquesm et al., for your feedback. I certainly don't want this to turn people away from Jobber, so I'll change it. Computers are frustrating enough; we don't need to add more aggravation!

On the other hand, IMO, the biggest profanity you can put in an error message is an error code and nothing more. Now THAT is how to mistreat your users!

I wonder if there were similar discussions about the insults sudo gives you on OpenBSD (http://prefetch.net/blog/index.php/2012/08/01/sudo-insults-w...)...

For the record, since it has been changed, L52 used to read:

fmt.Fprintf(os.Stderr, "Specify a command, asshole.\n\n")

Rather than the current:

fmt.Fprintf(os.Stderr, "Please specify a command.\n\n")

Not realizing this at first caused me a fair amount of confusion about what everyone was talking about.

And what's weird is that the 'asshole' got added in specifically.

https://github.com/dshearer/jobber/commit/7766f3fc2d61ba8008...

I'll give the benefit of the doubt and say this was an accidental commit after a frustrating debugging session but yeah, don't do this to your users.

I suspect we are going to see some upheaval in core services in the coming years...I'll be curious to see if systemd.timer takes the place of cron or if something else does. There is a good argument to be made for at least updating cron.

Link for systemd.timer: http://www.freedesktop.org/software/systemd/man/systemd.time...

And some discussion of using it to replace cron: https://wiki.archlinux.org/index.php/Systemd/Timers#As_a_cro...

Nice to see some activity in this space. gives me a little encouragement for my lil up-start. Maybe we could trade notes? http://ikura.co

Best of luck on your startup! It looks like your goals for Ikura are more ambitious than mine for Jobber --- e.g., Jobber doesn't spawn multiple instances of a job like Ikura does.

This looks very cool. Congrats on shipping. As a non-developer, (honest question) how does this compare to Airbnb's Chronos? I noticed you used Golang, and I'm guessing they have a better frontend. They taut "managed distributed solution". Any other differences?

Thanks for the congrats! Actually, it's not shipping quite yet --- it's still in beta.

Jobber is really just cron + support for error-recovery strategies like exponential backoff + support for getting the job execution history. It is very simple to deploy: it consists of just two (native) binaries, and has no dependencies (well, other than Bash).

Chronos also supports these additional features (although I don't know about exponential backoff), but Chronos is much more ambitious than Jobber. Probably the biggest differences are that Chronos supports farming jobs out to other nodes and that it supports dependencies between jobs. And of course Chronos has a nice GUI. On the other hand, I imagine it's a bigger deal to deploy, although I haven't done so myself.

So, if you have a bunch of related jobs that need to run on multiple nodes, Chronos would probably be best. Otherwise, try Jobber!

Congrats on shipping. Looks interesting - great idea to replace 'cron' itself with a better implementation.

(Shameless plug) - for those people that have to stick with cron (and cant switch to Jobber) and need status report and error handling I have a SaaS that handles this. See my bio for details.

Recovery of third party software seems to be the USP here (logging and reporting aren't hard to achieve normally).

I think I would have made a script to sit in-between, standard cron and third party software to solve the recovery problem where needed.

"When discussing jobs, by “job error” we mean the failure of a particular run of a job, whereas by “job failure” we mean a job that jobber has decided not to schedule anymore due to one or more recent job errors."

If you're using Ruby, whenever is a better solution.

https://github.com/javan/whenever

Wraps cron so you don't have to. Integrates with Capistrano.

KCSS (Keep Cron Simple, Stupid)

Why? Because "change is bad, mkkkay"?

It's not like Cron covers all our needs...

The "do one simple thing and do it well" principle worked best for the simple needs of late '70s OSes.

In 2014 it ends up with MORE (not LESS) complexity, built on top of those simple tools to coordinate them to do anything useful. And of course they're not even that smart in how they work together...

Like "make" has grown configure and autoconf and all that cruft (because we "kept it simple").

Cron already covers all my job scheduling needs, yes. You can do all the "recover thing" in the scripts called by cron, without the need of complicating 99% of cases that don't need such complication. "Keep it simple, stupid" is still valid for 2015, in my opinion.

About your off-topic comment: autoconf/automake adds crazy complexity. I avoid it as much as possible, using just Make (it allows you context detection and lots of conditional handling, without complicating things).

autoconf is insane. Just write your own configure script... Keeping it simple does not need to cause abominations like autoconf. I was glad to see the new ntimed project is not using it. Here's a comment from the custom configure script:

  # Handwritten configure script.
  # =============================
  #
  # Before you suggest I use tools for this, please read:
  #
  #     https://www.varnishcache.org/docs/trunk/phk/autocrap.html 
  # and
  #	http://queue.acm.org/detail.cfm?id=2349257
  #

from https://github.com/bsdphk/Ntimed/blob/master/configure

Reply on news.ycombinator.com