Is there a reason it would be a bad decision to use Bamboo ( or Jenkins ) to execute a scheduled task ( say every 15 minutes ) rather than using a cron job?

  • Yes, what type of task(s) are you running?
    – Preston Martin
    Apr 3 '18 at 15:00
  • Let's say that it's a task that takes 2 minutes to run and has to be run every 15 minutes. Apr 3 '18 at 21:08
  • Assuming it can be any sort of task: a bash script, a php script, a grunt task, a binary. Apr 4 '18 at 16:47

Using task schedulers like Bamboo or Airflow have a lot of advantages over cron, particularly in their ability to recognize errors and process dependent tasks accordingly. By far the most common reason not to use them is that you simply haven't set up the infrastructure yet: some form of cron is installed on every Linux machine, and it's easy to add a new job in, whereas these more advanced schedulers require setting up fleets of machines, installing and configuring various pieces of software, and learning how to write new tasks.

Assuming that you already have this in place, though, there are a few usecases that cron handles better:

  1. Running a job on a specific machine. You can do this with other schedulers, but they're generally designed for tasks that can be run on any one of a set of machines; when you want to do something like run a log rotation on every server in your fleet, that's much easier to set up with cron.
  2. Running time-sensitive tasks at exact times. Distributed schedulers will schedule a job to run, but it may not actually run for some period of time, depending on what else is in the queue. Cron doesn't have a queue, and so a task that needs to run every minute will run every minute (or at least as close to that as the OS scheduler will allow).
  • Just two remarks: any cron job output will be mailed to job owner, any non zero exit code will also trigger a mail even with no output, configuring mail alias is an usual task to have information about failures, linked to a ticketing system handling mail on critical tasks. Anacron allow loosely coupled tasks to run (do jobs which would have run during a downtime) as well as precise timing jobs along with usual cron definition IIRC
    – Tensibai
    Apr 5 '18 at 17:49
  • the timing of cronjobs is usually only good to the nearest minute unless you use gnu.org/software/mcron/manual/mcron.html or similar
    – Vorsprung
    Apr 6 '18 at 12:29
  • Emailing on error is good, but Airflow for instance has DAGs of tasks, and so it can abort running later tasks if a prereq task fails; they also only run the later tasks after the prereqs have finished, which is often a problem with cron when tasks take longer over time (due to processing a dataset that's growing). Regarding nearest minute, that's what I intended to say; distributed schedulers can often queue up tasks for five minutes (or way more!) if a bunch of jobs are triggered at the same time. Apr 6 '18 at 22:38

Possible reasons for using cron over jenkins

I am assuming you mean cron on a Linux system and not a Kubernetes CronJob Controller (https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/)

1) User permissions. Although you can work around this with Jenkins, it is possibly easier to run commands as arbitary users in cron

2) Provisioning of commands. You might want to be able to set up the commands with Puppet using a cron type. Again, I'm sure Jenkins can be configured in this way but it's possibly easier in some circumstances to configure cron

3) Lightweight. All Linux/Unix hosts run cron as a basic service that is always available. Whereas Jenkins requires extra non standard items to be installed and running

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.