I have googled several posts, but can't find anyone mentioning their build periodically not inspite of configuring the cron in right way.
I have the below setting for Build Periodically which I guess is correct, as I see the below comment. Still nothing happens. I have Jenkins 1.574 (latest stable build).
"Would last have run at Friday, 8 August 2014 07:01:40 o'clock BST; would next run at Friday, 8 August 2014 07:16:40 o'clock BST."
# every fifteen minutes (perhaps at :07, :22, :37, :52)
H/15 * * * *"
I have tried with several combinations like 15 * * * * / H * * * * / etc. But nothing seems to help. Can someone help me debugging and pointing me at right direction?
Thanks,
Raghu
I have faced same issue.
My Jenkins version 2.50 running on Ubuntu 16.04.2 LTS.
In order to get it resolved just create new job ( Do not copy ) with same configuration.
I really don't know what was the issue, but this is the solution I found.
Related
The program can't rotate the program log using the "rotate" property and "00:00" as the value. Run the program one day and the next day without the result of the rotation. I have tried it for several hours and have not had success either. On the other hand, it works correctly for me if I use "daily", but of course, I am interested in the rotation being carried out every day at 00:00. I would appreciate your help, any contribution will be highly valued.
Using poco-1.11.1
OS: Linux Mint 20.2 Cinnamon
Version: 5.0.7
linux core: 5.4.0-generic
Processor: AMD Ryzen 7 5700U
The provisionally developed code is:
// Configuracion canal fichero log
pCanalFich1->setProperty("path", "log.log");
pCanalFich1->setProperty("rotation", "00:00"); // CHECK THIS LINE PLEASE.
pCanalFich1->setProperty("archive", "timestamp");
pCanalFich1->setProperty("times", "utc");
pCanalFich1->setProperty("purgeCount", "5");
I assume you are using a FileChannel
See Slide 35 of the Logging slides here to see what you can set the rotation to.
I think you want:
pCanalFich1->setProperty("rotation", "daily");
I've seen several examples and all of them just trigger one job at a specific time, I have right now:
0 */5 * ? * *
and it triggers at mins 0,5,10, and on.
But, I need the trigger to run at +5 of the moment that the trigger was enabled.
So, if service becomes enable at 12:07 pm I need it to run then at 12:12 pm and on.
Is there a way to accomplish this?
Like you mentioned offsets are part of the solution to your problem.
0 */5+your_offset * ? * *
Now coming to what could be your offset:
Let's say cloudwatch-event bridge is enabled at some 12:07, (You can get that info from event details timestamp.)
your_offset = 7 + 5
// so your cron becomes : 0 */5+12 * ? * *
Or in general your
offset = the minute part of timestamp + 5
// for your to schedule 5 mins after service is enabled
Solution is simple:
Before create the rule check the minute time at that moment
time_minutes_now */5 * ? * *
I have a django crontab sceduled to run every 12 hours, meaning it should run twice per day however, it is running more than that.
Can anyone tell me what's wront with it ?
('* */12 * * *', 'some_method','>>'+os.path.join(BASE_DIR,'log/mail.log'))
Also what changes I need to make if I need it to run every 24 hours?
After every 12 hours you want to run job any particular minute from 0 to 59, not every other minute. So it should be (assuming 0th minute):
('0 */12 * * *', 'some_method','>>'+os.path.join(BASE_DIR,'log/mail.log'))
For once in a day or every 24 hours (You can decide any specific hour from 0 to 23, assuming at midnight):
('0 0 * * *', 'some_method','>>'+os.path.join(BASE_DIR,'log/mail.log'))
I am using the django-background-tasks 1.2.0 on Ubuntu 18.04 and Im running it with a cronjob. Is it possible that my cronjob somehow starts the tasks right before it is refreshed and then it gets stuck ?
It could be one or many stuck tasks at the same moment, depending on how many pending there are.
Cronjob:
* * * * * /project/manage.py process_tasks --duration=59 --sleep=2
settings.py
BACKGROUND_TASK_RUN_ASYNC = True
BACKGROUND_TASK_ASYNC_THREADS = 4
After six months of extensive testing the only way I don't get any stuck tasks is by running two parallel cron jobs that overlap each other and at the moment of refresh there is always one running. I ve tried with 1 running for longer period (3600 seconds) but i got to the same problem.
1 * * * * /project/manage.py process_tasks --duration=3600 --sleep=2
24 * * * * /project/manage.py process_tasks --duration=3600 --sleep=2
I hope it ll help you guys as well.
I hope following explanation will make sense because it's a weird problem we're facing and hard to describe.
We have a maven project which gets build in hudson and that contains some unit tests where dates are used and asserted. The hudson server runs on solaris. Now, occasionally (like 30% of the times) the unit tests using dates fail because 3,5 hours are deducted from the specified time in the unit test and hence asserts start failing. The other 70% everything works fine although nothing at all changed in the code and we run the hudson job several times an hour.
I add following code to a unittest to check the time:
#Test
public void testDate() {
System.out.println("new DateMidnight(2011, 1, 5).toDate();");
System.out.println(new DateMidnight(2011, 1, 5).toDate());
System.out.println(new DateMidnight(2011, 1, 5).toDate().getTime());
Calendar cal = Calendar.getInstance();
cal.set(Calendar.YEAR, 2011);
cal.set(Calendar.MONTH, 0);
cal.set(Calendar.DAY_OF_MONTH, 5);
cal.set(Calendar.HOUR, 0);
cal.set(Calendar.MINUTE, 0);
cal.set(Calendar.SECOND, 0);
cal.set(Calendar.MILLISECOND, 0);
System.out.println("cal.getTime();");
System.out.println(cal.getTime());
System.out.println(cal.getTime().getTime());
}
So basically it should print the same thing when using jodatime or plain old Calendar. This is the case in 70% of the runs; for the other 30% I get following printouts:
Running TestSuite
new DateMidnight(2011, 1, 5).toDate();
Tue Jan 04 21:30:00 MET 2011
1294173000000
cal.getTime();
Wed Jan 05 12:00:00 MET 2011
1294225200000
So, Calendar keeps the correct date and time but jodatime deducts 3,5 hours.
Local maven tests never appear the pose this problem and we can't figure out what could be the cause of it. Especially, we can't think of a single reason why the tests sometimes pass and sometimes fail without changing any code nor hudson or server setting.
Also, we run the maven install with cobertura which means that the unit tests are run twice. It happens also that they pass the first time and fail the second time or the other way around or that they fail both times.
Thanks for any solutions or tips to track down the cause,
Stijn
You may also be running into some version of SUREFIRE-533, which should be solvable by setting the TZ environment variable in the environment that is running hudson. Please report back on the issue if this helps.
Perhaps Hudson is running on 3 servers, and 1 has a different version of the time zone data in the JDK from the other 2? (check the JVM version in detail). Remember that Joda-Time also has its own version of the time-zone data, and the two may be different.
The problem seems to be fixed now.
We've upgraded our jodatime version from 5.14.2 to 5.14.6.
Since then I ran the build on auto each half hour so after about a 100 runs we never encountered this problem again.