Cron Job Issue with day of Month - cron

I have a cron job set to run a script once a day at 3am.
0 3 * * * /home/path/script.pl
It's been running without any problems since April 11th. Last weekend though, on Saturday the 3rd of May, the script was called once a minute for 24 hours. (1441 times in total) Then afterwards, on the 4th and 5th, it went back to only being called once a day at 3:00 again.
Does anyone have any ideas as to why this happened? I was wondering if there was an error in my crontab, since I have a 3 in it, and it was the 3rd of May that it happened. Since I only started running the cron since the 11th of April, I have no idea if it's something that will happen once a month on the 3rd, or if it was a one time thing unrelated at all.
I looked around and didn't find anything related, so I though I'd just ask while I continued to tried to find out what happened. I currently changed the cron to make it run at 6am instead to see if I'd end up with the same thing again tomorrow.
0 6 * * * /home/path/script.pl
EDIT
Everything was working fine, but then again on the 3rd of June, the same thing happened again. Could this be related to a cron problem or could it be something else entirely?

The problem was finally solved. There was a second cron being executed by root that was incorrectly written, which was making the script be called once a minute on the 3rd of the month instead of once a day at 3am.
The cron did not show up with the other cron jobs, and only by using the following command
did the cron job actually appear.
grep script /var/spool/cron/crontabs/*
I still don't understand but it's working correctly now.

Related

Cron expression to fire azure function twice every day

I have created a Timer trigger azure function which initially was as asked to run just once every day. But now its been asked to twice every day.
So I need to run it morning 2:30 and noon 13:15.
I wrote my cron expression like this
0 30,15 2,13 * * *
But my confusion is will it fire 2:15 and 2:30 and 13:15 and 13:30?
Yes, the expression you posted will fire at all four times, as you can see in the crontab.guru screenshot below.
The two explicit times you are requiring are not possible using a single cron expression.
Crontab guru is The quick and simple editor for cron schedule expressions.
Please be advised it does not take seconds into account, so remove the first element if you want to check something.

This is a cron-job in node.js

I am trying to make a cron-job that runs a function after 24 hours but if it's a friday, then the timer should stop at 23:59 and restart on sunday at 23:59. How do I do this?
Imagine a request being created. When this is created, an email function has to be called. If a reply for the said email is not received within 24 hrs, the email function should be called again and the 24 hrs timer should start again to repeat this process for a third time. But if it is a saturday and the timer is running, it should stop and then restart back on monday. (This is to indicate that no time from saturday or sunday has been consumed in the timer).
Some cron patterns allow you to specify day ranges (e.g. 59 23 * * 1-5 runs only Monday to Friday).
Fore more complicated logic, setting the cron to run everyday + inspecting the day of the week in your application might be simpler like O. Jones commented.
Personally, I'd lean towards the latter so you can log when the cron ran and skipped because it was a weekend, so you have a record, if things ever go wrong or you need to debug something.

Cron Scheduler use case

I am stuck and seek your help for my requirement , where I need to run a job everyday except on Sunday mornings from 05:30 AM to 08:30 AM.
I have searched and could not see the solution for my problem, could you be able to help me out to get the correct Cron Expression. I have also tried it using http://www.cronmaker.com/
i think the easiest solution in cron is:
start your program without any limit
stop your code at 5:30 AM on sundays
30 5 * * 7 stop_code
start your code at 8:30 Am on sundays
30 8 * * 7 start_code_again
Thank you all for your response.
I have used a CronRoutePolicy with respect to Camel as we were using Camel.
In the route policy i could define Start time , Suspend Time and Resume Time.
I have deployed it but some how quartz has not started the job. Figuring out the issue now.

Why crontab uses OR when both day of month and day of week specified?

It is a famous "problem" that when a crontab line contains both day of week and day of month cron uses OR for figuring out a day to fire the command.
E.g. if you write
* * 13 * 5 command
the command will execute on every Friday and every 13th day of month, not only on the Fridays that are 13th.
This contradicts the format for the other fields (when you write 30 2 * * * it will be executed only when both - hour AND minute - are exactly what you specified; same for all other fields except for DoW and DoM when they are both specified).
So my question is: is there a specific reason for this exception? I mean, there should be a reason, but I can't seem to find it. (And instead I see a lot of people in the internets who would like for these fields to be treated like any other - with the "AND strategy", precisely for stuff like "Friday 13th" or "2nd Thursday of May".)
Going back a step further from Vixie cron, the "wday OR mday" logic was present in System V cron, but not System III or anything earlier.
Before Paul Vixie wrote his cron replacement, BSD cron was like the SysIII-and-earlier cron. All 5 fields were ANDed. The post-4.4 BSDs adopted Vixie cron, making themselves more SysV-like.
So don't ask (blame) Vixie. He was just cloning SysV.
Why did SysV do that? I don't know but I'll try to provide some partial clues...
To try to understand what happened in SysV, it helps to look at the source (before - SysIII and after - SVr4) and also the documentation of the new behavior:
Note: the specification of days may be made by two fields (day of the month and day of the week). If both are specified as a list of elements, both are adhered to.
(Excerpt from SunOS 4.1.3 man page. It appears to be SysV-ish in this area. BSD cron never had this behavior before Paul Vixie wrote his replacement.)
"Both are adhered to" is a confusing substitute for a normal boolean expression using ANDs and ORs. It's still there in the OpenSolaris man page a couple of decades later:
The specification of days can be made by two fields (day of the month and day of the week). Both are adhered to if specified as a list of elements.
The SysV code is a complete rewrite. One of its features is that it sleeps for a long time when no jobs are due to run soon. (The older cron wakes up every minute and compares the current time to all job specifications.) A comment at the top of the calculation function (next_time) explains: NOTE: this routine is hard to understand.
It is indeed hard to understand. It is a "find next execution time for this crontab line" function, instead of a "decide whether the current time matches this crontab line" function, so it takes some effort to even figure out that the matching rule implicit in this function, when both mday and wday are non-*, is (month AND hour AND minute AND (mday OR wday)).
Based on that, combined with the way the documentation avoids explicitly telling us the boolean relationship between mday matching and wday matching, I'm going to guess that the person who wrote the new cron just wasn't thinking about it in those terms. They were thinking not about a combination of 5 booleans (corresponding directly to 5 fields in a struct tm), but about a set of 4 questions:
Is it the correct month?
Is it the correct day?
Is it the correct hour?
Is it the correct minute?
This leads naturally to the day comparisons being combined in their own way before ANDing everything else together. Maybe the SysV cron author just did what felt like the obvious thing at the time, without checking for compatibility with the old cron or pondering use cases like "first Saturday of every month".
Maybe this won't be a deep enough "why" to satisfy you - it certainly doesn't satisfy me - but a shallow answer is "because the standard says so".
Specifically, the POSIX standard dictates at http://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html that:
if either the month or day of month is specified as an element or list, and the day of week is also specified as an element or list, then any day matching either the month and day of month, or the day of week, shall be matched
(bolding mine).
I have no idea why this is what the standard requires. Interestingly, it seems like even Paul Vixie, who implemented Vixie Cron (the Cron implementation used on both Ubuntu and MacOS) doesn't know either; in cron.c there's this comment:
/* the dom/dow situation is odd. '* * 1,15 * Sun' will run on the
* first and fifteenth AND every Sunday; '* * * * Sun' will run *only*
* on Sundays; '* * 1,15 * *' will run *only* the 1st and 15th. this
* is why we keep 'e->dow_star' and 'e->dom_star'. yes, it's bizarre.
* like many bizarre things, it's the standard.
*/
So, by the sounds of it, even the implementer of the Cron you're probably using doesn't know the answer to your question in any more depth than the non-explanation I give in the first paragraph of this answer.
I work on a Unix server that uses many scripts in the crontab. It is very convenient for us to be able to indicate specific dates on scripts that should run on a single day of the week. In my case, I can't see why I would run a scheduled script on a day of the week ONLY if it is on a 13th, taking your example.

scheduled task on centos server

I tried now + time on centos, but it didnt work perfectly for me.
I want my centos server to run a script within 10 mins exactly after 5 days whenever the server is started, either it is started # 1pm or 5pm or 12 am or on the 7th day or 13th day i.e. recurring on server start after 5 days is over.
Can any one help please
Maybe I didn't understand your question... but did you already try with at command?
I mean something like this:
at now + 5 days < /path/to/yourscript.sh
Where yourscript.sh should have a loop waiting 10 minutes between each operation.

Resources