View on GitHub

Jobber

A replacement for cron, with sophisticated status-reporting and error-handling.

Download this project as a .zip file Download this project as a tar.gz file

Intro

Jobber is a utility for Unix-like systems that can run arbitrary commands, or “jobs”, according to a schedule. It is meant to be a replacement for the classic Unix utility cron.

Along with the functionality of cron, Jobber also provides:

License

Jobber's source code is copyright © 2014 Charles Dylan Shearer. It is licensed according to the MIT License:

The MIT License (MIT)

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Project Status

Jobber is curerntly at a “beta” level of maturity. The largest open task is to do a thorough security review — specifically, a review of how Jobber maintains privilege separation between different users' jobs.

Target Systems

Jobber is written in Go, and it should be possible to compile and run it on any modern Unix-like system. However, at this time its installation script targets RHEL, Fedora, and CentOS. (Actually, it has only been tested on CentOS....)

Installation

You need a recent version of Go to compile Jobber. Once you've installed Go and set up your Go workspace, you can build it thus:

cd /path/to/your/workspace
go get github.com/dshearer/jobber
make -C src/github.com/dshearer/jobber

As mentioned above, Jobber's installation script currently targets RHEL-like systems. If you are on such a system, you can install Jobber thus:

cd /path/to/your/workspace
sudo make install

Usage

Defining Jobs

As with cron, each user can have its own set of jobs, which will be run under that user’s privileges. A user’s jobs are defined in a file named “.jobber” in the user’s home directory. Jobfiles are written in YAML format. Here's an example:

---
- name: DailyBackup
  cmd: backup daily
  time: 0 0 13
  onError: Stop

- name: WeeklyBackup
  cmd: backup weekly
  time: 0 0 14 * * 1
  onError: Stop

This jobfile defines two jobs. Field “name” is self-explanatory. Field “cmd” can contain any Bash script.

Field “time”

Field “time” specifies when the job is run, in a manner similar to how cron jobs’ schedules are specified: with a space-separated list of up to six specifiers, which can be numerals or “*”. The first specifier constrains the second value of a given time, the second constrains to the minute value, the third to the hour value, the fourth to the day of the month, the fifth to the month, and the sixth to the day of the week. A job is scheduled thus: a job will run at the next time that satisfies all of these specifiers.

Thus, “DailyBackup” is run whenever the current time is 13:00:00 (i.e., 1 PM), no matter the day, whereas “WeeklyBackup” is run whenever the current time is 14:00:00 (i.e., 2 PM) and the current weekday is Monday.

Fields “onError”, “notifyOnError”, and “notifyOnFailure”

When discussnig 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. Jobber considers a run to have failed when the command (in field “cmd”) returns a non-0 exit status.

Field “onError” specifies what jobber will do when a job error occurs. The possible values:

Fields “notifyOnError” and “notifyOnFailure” control whether the user that owns a job is notified about job errors and job failures.

Loading Jobs

After you've created a user’s jobfile, log in as that user and do:

jobber reload

You can also reload all users’ jobfiles by logging in as root and doing:

jobber reload -a

Listing Jobs

You can list the jobs for a particular user by logging in as that user and doing

jobber list

This command also shows you the status of each job — that is, whether the job is being scheduled as normal, the exponential backoff algorithm is being applied, or the job has failed.

As with the “reload” command, you can do the same for all users by adding the “-a” option as root.

Listing Runs

You can see a list of recent runs of any jobs for a particular user by logging in as that user and doing

jobber log

As with the other commands, you can do the same for all users by adding the “-a” option as root.

Testing Jobs

If you'd like to test out a job, do

jobber test JOB_NAME

Jobber will immediately run that job, tell you whether it succeeded, and show you its output.