Answers: <p>Using task schedulers like Bamboo or <a href="https://airflow.incubator.apache.org/" rel="nofollow noreferrer">Airflow</a> 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.</p>
  
  <p>Assuming that you already have this in place, though, there are a few usecases that cron handles better:</p>
  
  <ol>
  <li><strong>Running a job on a specific machine.</strong>  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.</li>
  <li><strong>Running time-sensitive tasks at exact times.</strong>  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).</li>
  </ol>
  
Answers: CC BY-SA 3.0
Answers: 2018-04-05T17:49:52.533Z
Answers: 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
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2018-04-06T12:29:58.863Z
Answers: the timing of cronjobs is usually only good to the nearest minute unless you use  http://www.gnu.org/software/mcron/manual/mcron.html or similar
Answers: Vorsprung
Answers: CC BY-SA 3.0
Answers: 2018-04-06T22:38:39.430Z
Answers: 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.
Answers: Xiong Chiamiov
Answers: CC BY-SA 3.0
Answers: 2018-04-05T16:49:18.690Z
Answers: 2018-04-05T16:49:18.690Z
Answers: Xiong Chiamiov
Answers: <p>Possible reasons for using cron over jenkins</p>
  
  <p>I am assuming you mean cron on a Linux system and not a Kubernetes CronJob Controller (<a href="https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/</a>)</p>
  
  <p>1) User permissions.  Although you can work around this with Jenkins, it is possibly easier to run commands as arbitary users in cron</p>
  
  <p>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</p>
  
  <p>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</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-04-06T12:25:35.140Z
Answers: 2018-04-06T12:25:35.140Z
Answers: Vorsprung
Body: <p>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?</p>
  
Comments: CC BY-SA 3.0
Comments: 2018-04-03T15:00:09.537Z
Comments: Yes, what type of task(s) are you running?
Comments: Preston Martin
Comments: CC BY-SA 3.0
Comments: 2018-04-03T21:08:38.507Z
Comments: Let's say that it's a task that takes 2 minutes to run and has to be run every 15 minutes.
Comments: David Eugene Pratt
Comments: CC BY-SA 3.0
Comments: 2018-04-04T16:47:52.580Z
Comments: Assuming it can be any sort of task: a bash script, a php script, a grunt task, a binary.
Comments: David Eugene Pratt
Tags: <jenkins><bamboo>
Title: Is there a reason not to use Bamboo to run repetitive tasks instead of cron?
UserDisplayName: David Eugene Pratt
ThreadText: # Is there a reason not to use Bamboo to run repetitive tasks instead of cron?
  
  (Asked by: username_0 on 2018-04-03)
  
  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?
  
  **Tags:** jenkins, bamboo
  
  > **Comments:**
  > **username_1**: Yes, what type of task(s) are you running?  
  > **username_0**: Let's say that it's a task that takes 2 minutes to run and has to be run every 15 minutes.  
  > **username_0**: Assuming it can be any sort of task: a bash script, a php script, a grunt task, a binary.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2018-04-05. Score: 3
  
  Using task schedulers like Bamboo or [Airflow](https://airflow.incubator.apache.org/) 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).
  
  > **Comments:**
  > **username_3**: 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  
  > **username_4**: the timing of cronjobs is usually only good to the nearest minute unless you use  http://www.gnu.org/software/mcron/manual/mcron.html or similar  
  > **username_2**: 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.  
  
  ---
  
  ### Answer by username_4 on 2018-04-06. Score: 1
  
  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
  
  
  ---
  
  