In our production environment we had to review and replicate all the CRON jobs running on one of the stacks to the other new stack. Since the stack consists of multiple nodes clustered together running Jboss and another cluster of tomcat nodes, we would have to collect the details from all the servers.
By definition CRON has a single-tier architecture. This means that it is running as a single process on a single machine without any agents or server to communicate with. It also means that each instance of CRON is isolated and a problem in one of the instances on one of the machines would not affect others. This prevents it from becoming a SPOF (Single point of failure) but increases the maintenance and data aggregation overhead. Any changes have to be installed on all the nodes instead of a central machine. Therefore, each scheduler must reside on its own machine and contain its own database. Since there is no integration between the schedulers on the various machines, it is not possible to transfer jobs from one machine to the other, even if one machine has a heavy workload.
To view all the cron jobs on a machine by a user use
- crontab -u exampleuser -l
You can create a cron job from that file as follows:
- crontab /tmp/my_cron_jobs.txt
(Or for exampleuser:
- crontab -u exampleuser /tmp/my_cron_jobs.txt
For more information on creating and editing a cron job refer this and this.
Control-M by BMC software, takes the scheduling and execution of jobs at a higher level of abstraction where in all the jbos can be defined on multiple nodes using a central console. The results would be available on the central dashboard and can be tracked. Alerts are generated from the central location. There is failover support too.
For more differences between Control-M and Cron, refer to this pdf.
Posted in General, linux
