I need to schedule job to run twice a day everyday i.e. first run at 1 AM and second run at 11 PM. As you can see there is no way I can use option "repeat range".
So my question is what is the better way to do it:
1. set two run cycles (DAILY and DAILY2), check the "use as time dependency" and set the earliest start for each
2. create two identical jobs (with different names) and set the time restriction on the job level (under one run cycle DAILY)
It seems like there is no difference, but in TWS you never know so what do you recommend? Thanks
I would use 2 different runcycles with different start times defined at runcycle level.
The use of "use as time dependency" is optional in this scenario, this is up to you if you want to not start before 1 AM / 11 PM or if this is just to create 2 instances with 2 different schedTime and resolve the dependencies according to these schedTimes.
Related
Is there any way to run the job every day from Monday to Friday at 45 mins time interval from 2.45 pm to 5 pm. (The job should run at 2.45pm , 3.30pm, 4.15, 5.00). Please help.
Thank you.
I know of two ways:
One way is to create four jobs scheduled at a single time every Mon-Fri. Give each a single step, which is a job reference to the real job. For example, the first job would be scheduled to run at 2.45pm every Mon-Fri, the second at 3.30pm, etc. You're not making copies of the existing job, just single-step jobs that reference the original.
That approach lets you manage each scheduled time individually.
Another way is to schedule it every 15 minutes from 2.00pm to 5.45pm, and add an initial step that fails if the time is before 2.45pm or after 5.01pm. If you don't want to see these failures, you could add an error step to that first step which marks the job succeeded even if it's really skipping all the real steps.
Paul M. Lambert
Platform Solutions Architect
Rundeck, Inc.
I'm setting up Airflow right now and loving it, except for the fact that my dags are perpetually running behind. See the picture below - this was taken on 2/19 at 15:50 UTC, and you can see that for each of the dags, they should have run exactly one more time between the last time they ran and the present time (there are a couple for which this is not true - those ones are currently turned off). Is there some piece of configuration I missed?
False alarm! Airflow just labels execution times differently than how I expected. Turns out an hourly job that runs at 15:00 is labels "14:00" and includes data up to 14:00+1:00.
From https://airflow.apache.org/scheduler.html:
Note that if you run a DAG on a schedule_interval of one day, the run stamped 2016-01-01 will be trigger soon after 2016-01-01T23:59. In other words, the job instance is started once the period it covers has ended.
Let’s Repeat That The scheduler runs your job one schedule_interval AFTER the start date, at the END of the period.
Execution time is the lower bound of the batch.
Ex:
Say your execution schedule is hourly and its the run corresponding to the 13:00 schedule.
Your execution_time will be 12:00.
This is because we usually run the batch for 12:00 - 13:00 at 13:00(after the data is available for the batch).
But in my experience, we sometimes use the schedule based on the time its scheduled for(because we want the schedule to start and there are checks inside of the DAG/job that verify data readiness). In those cases, I just end up using next_execution_time(13:00) instead of execution_time(12:00).
I have a single agent and many builds. There are frequently several builds in the queue that take an hour a piece to execute. I want to trigger daily at a specific time a build which takes less than five seconds but needs to run immediately (next in the queue). Is there any way to do this?
Build priorities are suggested in various places but they do not help. I set the priority to the max value of 100 and it was placed at 15 out of 17 in the queue.
You can use Teamcity REST to trigger the build and put on top of the queue. You can make use of triggering option queueAtTop="true"
I ended up working around the problem and moving this build to another practically dedicated teamcity agent which means this executes promptly. This is not a good solution and I would prefer to accept an actual answer if anyone is able to offer one.
I have a build with a finish build trigger and i want to limit it to run only in specific time domain (e.g. between 4 AM to 5 AM) regardless to the finish build trigger, any suggestions?
Another solution is to pause build configuration. You can pause build configuration using REST API.
You could remove the finish build trigger and add an extra step to the triggering build which calls the rest api.
By adding a bit of logic around the call the check the time is in the required range, you should be able to achieve what you are after.
You can use cron-like expressions to write schedule triggers that will trigger your build at customized times. You can read the teamcity specs here
For example , if you want to run a target everyday at 4.30 AM , you would have to define it in the following syntax.
Seconds 0
Minutes 30
Hours 4
Day-of-month *
Month *
Day-of-week ?
I have to set up a cron job on my hosting provider.
This cron job needs to run every second. It's not intensive, just doing a check.
The hosting provider however only allows cron jobs to be run every two minutes. (can't change hosting btw)
So, I'm clueless on how to go about this?
My thoughts so far:
If it can only run every two minutes, I need to make it run every second for two minutes. 1) How do I make my script run for two minutes executing a function every second?
But it's important that there are no interruptions. 2) I have to ensure that it runs smoothly and that it remains constantly active.
Maybe I can also try making it run forever, and run the cron job every two minutes checking whether it is running? 3) Is this possible?
My friend mentioned using multithreading to ensure it's running every second. 4) any comments on this?
Thanks for any advice. I'm using ZF.
Approach #3 is the standard solution. For instance you can have the cron job touch a file every time it runs. Then on startup you can check whether that file has been touched recently, and if it has then exit immediately. Else start running. (Other approaches include using file locking, or else writing the pid to a file and on startup check whether that pid exists and is the expected program.)
As for the one second timeout, I would suggest calling usleep at the end of your query, supplying the number of milliseconds from now to when you next want to run. If you do a regular sleep then you'll actually run less than once a second because sleeps sometimes last longer than expected, and your check takes time. As long as your check takes under a second to run, this should work fine.
I don't think cron allows second level resolution. http://unixhelp.ed.ac.uk/CGI/man-cgi?crontab+5
field allowed values
----- --------------
minute 0-59
hour 0-23
day of month 1-31
month 1-12 (or names, see below)
day of week 0-7 (0 or 7 is Sun, or use names)
So, even if your hosting provider allows you can't run a process that repeats every second. However, you can user command something like watch for repeated execution of your script. see here