[Unbelievably] Simple Enterprise Job Scheduling/Management
Friday 06/26/20 at 10:36:44 PM

Jobber is a simple solution for centrally managing scheduled jobs across many systems. Jobber uses UNIX/Linux cron in addition to isitme (part of Jobber) to determine which user (EUID - effective user id) a job will run as, what time a job will run at and what hosts a job will run on. Jobber makes use of /etc/crontab as the central configuration resource for establishing all jobs. This file can then be distributed to all hosts via a variety of methods (Puppet/Chef, SCP, Rsync, etc.).


Latest Jobber Source

How Jobber Works

Once jobber and isitme are copied to all hosts that need centralized job control, something similar to the following can be added to /etc/crontab:

    Time     User         Host    Job  

*/5 * * * * Puppet jobber puppet pmaster
*/5 * * * * Puppet jobber puppet pupdate
*/2 * * * * Apache jobber apache ApachePush
*/5 * * * * Yum    jobber yum    YumPush

The /etc/crontab file allows for job entries to be established with an additional user field. This is ideal for those that like to establish 'job' or 'role' accounts for jobs that make use of automated authentication and process execution. Other than the user field, job entries in /etc/crontab are standard cron entries that establish an execution schedule and a job to run. In the case of a job that is Jobber controlled, cron runs jobber with two command line options:

  1. The hostname or service name representing the host[s] that will execute the job. Here we define 'service name' as a group of hosts that fulfill the same need (often cooperatively) and are likely identically configured.
  2. The job {binary,script} to be executed.

Jobber then acts as a wrapper with 3 primary functions:

  1. Call isitme, passing the hostname or service name to see if the current host running jobber matches the hostname or one of the hosts that make up the service.
  2. Execute the job {binary,script} that has been passed to jobber.
  3. Log (to syslog) the job name and the status of the job.

A job's status is either "Executed", "Failed" or "Skipped". If the current host matches the hostname or one of the hosts in the service passed to Jobber then the job will execute. If it does not then the job is skipped. This means all hosts that receive the centrally managed /etc/crontab file will attempt to execute scheduled jobs.

Jobber logs all job execution to syslog (regardless of a job's final status). This + Massh result in simple means to check job exection status no matter how many hosts are involved. The following shows that the job 'webpush' executed on 1.a.tt and not on the other two hosts:

1 $ massh -r att -c 'tail -5 /var/log/cron | grep JOB=webpush' -o | grep -v Failed
1.a.tt : 2011-03-19T07:45:02.378388-04:00 1 jobber[32491]: JOB=webpush STATUS=Executed
2.a.tt : 2011-03-19T04:45:01.512791-07:00 2 jobber[16464]: JOB=webpush STATUS=Skipped
3.a.tt : Mar 19 04:45:01 3 jobber[10349]: JOB=webpush STATUS=Skipped

Using Massh's -S (Success) option it is possible to verify the host by hostname only (Massh will only return the hostname[s] where the command ran successfully):

1 $ massh -r att -c 'tail -5 /var/log/cron | grep JOB=webpush.*E' -S 

This site will always use valid XHTML and valid CSS.

© AfterTheTweet.com 2021