Ricardo SIGNES > App-Cronjob-1.200001 > cronjob


Annotate this POD


View/Report Bugs
Source   Latest Release: App-Cronjob-1.200003


cronjob - wrap up programs to be run as cron jobs


version 1.200001


  cronjob [-cEfjrs] [long options...]
    -c --command          command to run (passed to ``)
    -s --subject          subject of mail to send (defaults to command)
    -r --rcpt             recipient of mail; may be given many times
    -E --errors-only      do not send mail if exit code 0, even with output
    -f --sender           sender for message
    -j --jobname          job name; used for locking, if given
    --ignore-errors       error types to ignore (like: lock)
    --lock                lock this job (defaults to true; --no-lock for off)


cronjob is a fairly simple Perl program that's meant to be used to wrap anything you want run from a crontab. It was originally written to cope with the highly deficient Solaris crond, but now provides features that are useful even under relatively sane and otherwise tolerable cron daemons.

The most important argument to cronjob is --command (aka -c). It gives the command to be run. If you want to run some-maintenance-job every day at noon, you might put this in your crontab:

  0 12 * * *           cronjob -c 'some-maintenance-job --xyzzy'

Here's what will happen when that job is run:

Unless you provided --no-lock, an exclusive lock will be created on a temporary file in /tmp. The locking process is described more below. Basically, it tries to prevent more than one of the same, or closely-related, jobs from running concurrently.

The job will be run with no input. Its combined STDOUT and STDERR are captured, along with its exit (wait) status.

When the command has terminated, a report is sent if:

The report will include a summary of the process and its behavior, including the time taken to run, the exit status, any signal received, and whether core was dumped. It will also include the full (combined) output of the process.

The report will be send from --sender (or a reasonable default) to --rcpt (or root). Its In-Reply-To header will be set to a hashed value that will cause all same-subject jobs to thread together in threaded mail readers. The --subject switch sets the message subject, so it's responsible for deciding which jobs thread together. For jobs that run with variable arguments, providing a --subject argument is a very good idea.


The default lockfile name is generated with code something like this:

  my $lockname = $opt->jobname || ( md5_sum( $opt->subject || $opt->command ) );
  my $lockfile = sprintf '/tmp/cronjob.%s', $lockname;

In other words, if you specify a --jobname option, that will be used for naming the lockfile. This lets you force otherwise unrelated cronjobs to block each other. If you don't provide a job name, one is created by hashing the subject (of the report to send) or, failing that, the command itself. The hashing is a simple measure to prevent long or metacharacter-ridden filenames.

The lockfile will contain information about the process that has the lock, including when it was begun.

By default, all jobs are locked and failure to acquire a lock causes immediate failure of the cronjob. A failure report will be sent. To suppress failure reports in the event of lock failure, pass --ignore-errors lock to the command. To skip locking, pass --no-lock.

Note that ignoring lock failures only ignores failure to flock the lockfile. If the file can't even be created, an error will still be reported. It will be of type lockfile, and can be ignored by adding another --ignore-errors option for that type.


Ricardo Signes <rjbs@cpan.org>


This software is copyright (c) 2009 by Ricardo Signes.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.

syntax highlighting: