Run Script On Cron Job Only Run On First Saturdat Every Month???

Home » CentOS » Run Script On Cron Job Only Run On First Saturdat Every Month???

20 thoughts on - Run Script On Cron Job Only Run On First Saturdat Every Month???

  • I don’t believe cron has any concept of the first day-of-week of each month, so you’ll need to put some code into your script to exit if its NOT the first day-of-week of each month.

  • John R Pierce wrote:

    It certainly doesn’t. However, I’m surprised the o/p’s crontab entry
    *doesn’t* work: it should run only on Sat, and only on when it’s somewhere between the 1st and the 7th, which could only be the first Sat.


  • The conditions are ORd, so the job should run every Saturday and every day from the first to the seventh (which will include a Saturday). John is right: most crons do not support “Nth X of the month” where X is a day of the week. (I don’t know of any.)


  • That’s pretty clever, and it looks like it should work. Maybe something is taking priority?
    I’d try some experimentation.

  • Run an incremental backup every day of the month except sundays

    03 03 1-31 * * test `date +\%a` != Sun && /usr/local/bin/backup-rsch-

    Run a full backup on the first sunday of the month

    07 03 1-7 * * test `date +\%a` = Sun && /usr/local/bin/backup-rsch-


  • Tony Molloy wrote:

    I agree with the original poster: why doesn’t his work, which says 6 in the location for day of week, which is Sat.? I’d think it meet the criteria “it’s somewhere between the 1st and the 7th of the month, and it’s a Sat”, and that I think should be the same as yours….


  • As Keith said, it’s because the conditions are OR’d. A careful reading of crontab(5) shows that the algorithm is [minute AND hour AND (restricted day of week OR restricted day of month) AND month]. Day of week and day of month only restrict independently when one or both is “*”.

  • Tony Molloy wrote:

    Ok, I just mentioned this to my manager, and he told me why: he said he’d been bitten by this before, and what’s happening is that the logic of cron is odd: it’s an OR, *not* and AND, so it’s saying “if it’s a Sat, *or* if it’s the first seven days of the month….


  • 1 2 3 4 5 /root/

    * * * * * command to be executed
    – – – – –
    | | | | |
    | | | | —– Day of week (0 – 7) (Sunday=0 or 7)
    | | | ——- Month (1 – 12)
    | | ——— Day of month (1 – 31)
    | ———– Hour (0 – 23)
    ————- Minute (0 – 59)

    15 4 1-7 * 7 /home/app/oracle/backup/

    ^ ^ Mark LaPierre Registered Linux user No #267004

  • > 15 4 1-7 * 7 /home/app/oracle/backup/

    Can you please point out what’s wrong with

    15 04 1-7 * 6 /home/app/oracle/backup/

    that makes it run every saturday instead of only the first saturday of the month?

    (Going by the breakout matrix provided in your reply, it looks like your solution should make it run the first Sunday of every month.)


  • We have already gone over this. The days columns are effectively ORed. So the above job runs every day from the 1st to the 7th, and every Saturday of the month. Read man 5 crontab to see this documented.


  • Right, but the proposed command doesn’t make it much different… instead of the 1st through 7th plus every Saturday as it should currently be running,

    15 4 1-7 * 7 /home/app/oracle/backup/

    would make it run the 1st through the 7th and every Sunday… when what was requested was running it only the first Saturday of the month.

    It seems to me if the asker wants to run it only 1 day per month, they’re going to have to pick a day and put up with the fact that sometimes it’s going to happen during weekdays, unless they want to twiddle with it every month. e.g.

    15 4 1 * * /home/app/oracle/backup/

    should make it run only on the 1st of the month at 4:15am. (right?)

    Anyway, thanks for the reply. :)

  • or… if it really has to be on the first Saturday and only on the first Saturday, then running something like
    15 4 1-7 * * /home/app/oracle/backup/

    with the top of the script doing soemthing like if [`date +%u` -eq 7 ]
    echo “saturday! backup day… writing our drives with yoooouuuu… ”
    echo nah, wait till saturday.
    exit 0

    …. rest of your backup stuff.

    it’s not exactly elegant, but it does seem to get a fix for the original ask.

  • No, really. We went over this. You don’t have to modify your scripts.
    You can put the “test” in the crontab. John’s example should work properly:

    15 04 * * 6 test $(date +”%d”) -le 07 &&

    Cron will run those commands every Saturday. On the first Saturday in the month, “test” will succeed and the script will be run.

  • Definitely untested! You need to escape the “%” sign, since it is special to cron. Plus, you need to prevent the date command from padding its output with a leading zero, since that would result in the illegal octal numbers 08 and 09:

    15 04 * * 6 test $(date +”\%_d”) -le 7 && /home/app/oracle/backup/

  • On the other hand, putting the test in the script – perhaps with a command line option to override – would also keep it from doing something wrong even if someone happens to run it manually at the wrong time. If I were doing it, I might touch a file when starting and check the timestamp of that to avoid running more than one even on the right day. Sometimes the most clever way isn’t really the best.

  • We do what Les is suggesting. Our script runs the second Saturday of the month (just to be difficult), and is broken into two parts. The part called by cron via “0 9 8-14 * *” does the checking and then calls the real script only if all the conditions are met: it’s a Saturday, it’s not already running, etc etc. The nice thing about this way is that in the unfortunate case that something went wrong with the cron-fire and we have to manually run the script, we can just do that on the command line without worrying about it not running because out of umpteen tests one failed and killed the execution. And, the initial script is tailored to the machine on which it runs, whereas the main script is the same on all the machines where it runs, so that’s handy as well.