Bug 173795 - Cron seems to ignore Day Of Month
Summary: Cron seems to ignore Day Of Month
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: cronie
Version: rawhide
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-11-21 10:29 UTC by Phirsk
Modified: 2016-05-12 10:20 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-12 10:20:55 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Phirsk 2005-11-21 10:29:22 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

Description of problem:
In crontab, I have a command in the following format:
30 8 1-7 * 0 /<path-to-script>

This should execute the script on the first Sunday of each month, but instead executes it every Sunday, ignoring the "1-7" setting.

Version-Release number of selected component (if applicable):
crontabs-1.10-7

How reproducible:
Always

Steps to Reproduce:
1. Create an entry in crontab with the above format.
2. Wait until Sunday, and it will execute, regardless of whether it is the 1st Sunday of the month or not.

Actual Results:  The script executes, even when it should not be.

Expected Results:  The script should only run on the 1st Sunday of each month, i.e. where the day is Sunday and the day of month is between 1st and 7th.

Additional info:

Comment 1 Jason Vas Dias 2005-11-21 16:26:38 UTC
This issue is noted in the crontab(5) man-page:

"      Note: The day of a commandâs execution can be specified by two fields â
       day  of  month,  and day  of  week.   If  both fields are restricted (ie,
       arenât *), the command will be run when either field matches the current
       time.  For example, ââ30 4 1,15 * 5ââ would cause a command to be run at
       4:30 am on the 1st  and  15th  of  each month, plus every Friday.
"

So your specification:
       30 8 1-7 * 0 /<path-to-script>
would run when EITHER the day-of-week is 0 (Sunday) OR the day-of-month is
between 1 and 7 .  

This is the way vixie-cron is currently designed to work, and hence this is 
not a bug. We could not change this default behaviour without causing problems
to users who relied on it.

But I will consider this bug as an enhancement request to provide some kind of
"AND" option that would make the condition true only if ALL time specifications
matched for a job, as done by the fcron package.

Comment 2 Gilles Detillieux 2007-04-27 15:41:47 UTC
As a workaround, you can add the following to the start of your script, so that
it will exit unless it detects that it's running on the first Sunday of the month:

case "`LOCALE=C date`" in
Sun\ ???\ \ [1-7]\ *) ;;       # OK, first Sunday of month
*)                    exit ;;  # otherwise quit
esac


That way the script could run every Sunday (or even every day, or the first 7
days of the month) and only continue on if it is indeed the first Sunday of the
month.  Similarly, you could replace the "???" with the 3-letter abbreviation of
a specific month if you wanted to run on the first Sunday of that month, e.g.
"Jan" to run on the first Sunday of the year.  You could get even more elaborate
by using the "+FORMAT" option to the date command (see "man date") to select on
all sorts of date/time fields.

You may find with this technique that there's really no need to change the
crontab format to accomodate more complicated combinations of time specifications.

Comment 3 Marcela Mašláňová 2007-08-14 13:57:10 UTC
You can also use @monthly in /etc/anacrontab, if you want only one run per
month. But I like to add to cron AND, OR option, which allow this (#0) behaviour.

Comment 4 Fedora Admin XMLRPC Client 2014-09-04 12:14:53 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.


Note You need to log in before you can comment on or make changes to this bug.