Is Jobber a Decent Replacement for Cron?

1

According to their site :

Along with the functionality of cron, Jobber also provides:

  • Job execution history: you can see what jobs have recently run, and whether they succeeded or failed.

  • Sophisticated error handling: you can control whether and when a job is run again after it fails. For example, after an initial failure of a job, Jobber can schedule future runs using an exponential backoff algorithm.

  • Sophisticated error reporting: you can control whether Jobber notifies you about each failed run, or only about jobs that have been disabled due to repeated failures.

  • DEB, APK (for Alpine) and RPM available on download page.

Examples and Syntax

Anyone using this ?

2 Likes
2

Sounds intriguing, I would also be interested to see if anyone else has used this.

3

Here you can find a comparison between Crontab and Rundeck.

I have to say, Rundeck looks awesome.

There’s a paid “Enterprise version” and a community version on Github

Another (commercial) contender is JAMS

1 Like
4

Written in Python, Hcron takes a different approach, with key / value pairs.

Despite its last update being from 2010, it’s still interesting to have a look at its source code.

1 Like
5

SysVinit and Vixie cron for life.

2 Likes
6

With those you will never know for sure each job has finished without errors, or with multiple retries.

7

Uhh. MAILTO= is still a thing fwiw.

8

true

Though I prefer a log file instead of an emailbox full of messages.

1 Like
9

This topic and

in particolar reminded me an old querelle on RH’s bugzilla, about the replacement of ye olde cron with the swiss army knife SYSTEMD OF DOOM

On one side the maintainer (Sorensen, linux plumber):

Why the obsession getting rid of cron? It works just fine and is simple to
use.

then, a reply by someone who even provided a patch (never applied, IIRC: and if I’m correct only Arch offers some kind of AUR for raid.check in systemd)

As for rationale, here are couple of points I like as a sysadmin:

  • systemd scheduling is easy to administer and analyse, crond isn’t. For example, ”systemctl list-timers” shows next occurence of timer, along with previous events:

NEXT LEFT LAST PASSED UNIT ACTIVATES
Sun 2015-01-18 01:00:00 CET 2 days left n/a n/a raid-check.timer raid-check.service

  • systemctl: single, coherent way of checking state of services, no matter if run from periodic events or manually

  • protection against running more than one instance of job by mistake (what cron does when single raid-check takes more than 1 week?)

  • single place (systemctl status) to check the state and logfiles of last periodic job invocation

  • single coherent way to mask/disable services for an administrator,

  • easy way to override shipped defaults without conflicts on package upgrade

  • less dependencies, minimising smallest installation image - no need to depend on cron (nb. mdadm package lacks this dependency now)

Personally I have no use for some web gui with all those bells and whistles (I’m looking at rundeck now) just to allow my users (=me) to tap on some settings and obliterate servers on the go, even if Ansible is one of the tools I may use (and it’s recalled in one of those pages)
I always rush to remove any web panel unsavorily installed “per default” in same cases, I trust my tmux+ssh more than a public-facing Web-UI, chances are I am not “ready to :rocket: scale”
It’s true that I rely on Telegram notifications more than on e-mail sometimes

1 Like
10

@mfs

I took the systemd scheduling solution into account too, but found the configuration a bit cumbersome compared to the light-footed Yaml / Jobber configuration.

Both work fine and get the job done without endless mails and single tries like crond.

And Rundeck, yes, as you said :blush: