![]() ![]() Let me know if you have feedback, or see something I missed. You can read further details in Wikipedias article about Cron and check a cron expression online with. additional reference, read with grain of salt.The redirection to /dev/null along with the additional directives averts spamming someone's email, or filing up mqueue or /var/spool/mail/elvis if the mail daemon is not functioning (or someone's email if the script goes sour, you can put in error checking in the script and send notifications if needed).The critical part is the "tue" where it runs only on a Tuesday.The 2nd Tuesday can range only from 8-14, and no lesser. It runs on only on days 8-14 where there is no possibility of a duplicate instance of running on a Tuesday, because the first Tuesday can only be a range from 1 through 7, and no greater.The proposed cron runs on the third minute.# third minute, third hour, days 2 through 15th, the four months, only on a tuesday # 3 3 8-14 jan,apr,jul,oct tue /home/elvis/scripts/some_report.bash > /dev/null 2>&1 # m h day month day of week /home/elvis/scripts/some_report.bash > /dev/null 2>&1 # these are "commented out" with the "#" character, however, these are examples day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat I believe this is correct: # For details see man 4 crontabs There are no instances of the 7th being the 2nd Tuesday obviously. On the least end, the least possible 2nd Tuesday would be the 8th. If the first of any given month begins on a Wednesday, the resulting "largest" 2nd Tuesday will be the 14th (run cal 2022 for an example). For the 2nd Tuesday, the span of possible "days" of the month the second Tuesday could land on are from day 8 through 14. ![]() Do you, for example, want to avoid creating the state file if the command fails? You may also want to create the state file elsewhere in a safe location that is unlikely to be cleared out by maintenance scripts and where it is unlikely to overwrite other data or be overwritten by other projects running on the same machine.Did some looking at this. The exact logic that you want to use here depends on your requirements. let cron inform you of a failed run, then ensure that your wrapper script exits with the exit status of the command: #!/bin/sh Note that this does not take care to preserve the exit status of the command ( cmd in the above examples). The cron-wrapper shell script could look something like this: #!/bin/sh Obviously (?) this would be cleaner if the business logic was encapsulated in a shell script that was triggered by the cron schedule: 15 5 * * 2 /some/path/cron-wrapper ![]() So your schedule could look like this: 15 5 * * 2 if then rm -f /tmp/statefile else cmd touch /tmp/statefile fi If the file does not exist, the command is run, and then the job creates the file. If the file exists, it is removed, but the job does nothing else. The easiest way to get your command to run every second time this schedule triggers it is to let the cron job keep its state as a temporary file. Or use the day name (this may not be supported everywhere), 15 5 * * tue The cron schedule for running a job at 05:15 on Tuesdays is 15 5 * * 2 ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |