Crontab error bad hour

Depending on your flavor of cron, it may not love the / notation.

Rather than trying to make it super-compact, just tell it what you want it to do in a more acceptable to most/all versions of cron fashion. Might have the advantage of being more obvious to more humans, too. It’s a simple system — you really shouldn’t need a «tool» to create a crontab beyond a text editor. Since noon happens after 9, you only need to provide a «special case» for 9, 10 and 11 on Sunday and Saturday.

# every day at 2 minutes past the hour from Noon to 11 PM
2 12-23 * * * tills13 python3 /home/tills13/script.py --sync
# weekends at 2 past the hours of 9, 10 and 11
2 9-11 * * 0,6 tills13 python3 /home/tills13/script.py --sync

Should also work for weekend (Sunday is 0 and 7):

2 9-11 * * 6-7 tills13 python3 /home/tills13/script.py --sync

if you want every hour at 2 minutes past.

I haven’t bothered to decode the / notation fully, (don’t recall it from my cron days 30 years ago and the wikipedia article is not comprehensive WRT it) but if you actually want every 2 minutes, just list them — 2,4,6,8,10,12 (etc)

9-11 in the hour field is equivalent to 9,10,11 (for example) and can be written either way and work. If you’d prefer to run ON the hour, change 2 in the minutes field to 0.

Minute Hour Day-of-Month Month Day-of-Week Command is all there is to standard crontab notation, with ranges of 0-59, 0-23, 1-31, 1-12, and 0-6 (but 7 is commonly accepted as 0 here) — the time fields can have comma separated lists or dash-separated ranges, or the * means all — whitespace separates the fields.

In this article, I will explain about the «errors in crontab file, can’t install» error which I was getting while setting up the Crontab. This error is very common and can come up due to various reasons hence it is important to understand the crontab parameters. I will go through multiple scenarios in which this error could occur and how can we resolve this. But before that it is important to understand the crontab parameters through below example.

*    *    *    *    *    /home/centos/example.sh
|    |    |    |    |            |
|    |    |    |    |    Command or Script to execute 
|    |    |    |    |
|    |    |    | Day of week(0-6) 
|    |    |    |
|    |    |  Month(1-12)
|    |    |
|    |  Day of Month(1-31) 
|    |
|   Hour(0-23) 
|
Min(0-59)

Also Read: 11 Unix/Linux chmod Command examples to Change File Permissions

Scenario 1: When number of crontab field is more than expected

I have been trying to set crontab from User root by running crontab -e command. After setting up the required fields I tried to save the crontab file multiple times but every time I got below error and it was not allowing me to save the file.

[root@localhost ~]# crontab -e
no crontab for root - using an empty one
crontab: installing new crontab
"/tmp/crontab.gsQNhu":1: bad command
errors in crontab file, can't install.
Do you want to retry the same edit? y
crontab: installing new crontab
"/tmp/crontab.gsQNhu":1: bad command
errors in crontab file, can't install.
Do you want to retry the same edit? y

-e : Edits the current crontab using the editor specified by the VISUAL or EDITOR environment variables. More can be checked on crontab Man Page.

Below is what my crontab file looks like when i got the above error. If you see the below output carefully then you will see an extra star(*) field due to which above error was showing.

0 3 * * * * /home/centos/example.sh

To resolve this issue i have removed that extra star(*) mark and then saved the file again. Then i am able to see below output which shows that crontab is successfully saved.

crontab: installing new crontab

Scenario 2: If you forget to mention the Script in Crontab File

Another scenario could be when you forget to mention the Script in Crontab File like the one showing below. Sometimes you might forget to mention the Script file which needs to run as part of cron job and then try to save the file. In those cases also you will get the same "errors in crontab file, can't install" error.

0 2 * * *

To fix this error you need to edit the crontab file and mention the script file name that needs to be run as part of the cron job.

Scenario 3: You might get «errors in crontab file can’t install bad minute»

I have also seen a scenario where sometimes we might add an extra line like the one mentioned below then if you try to save this crontab file you will get "errors in crontab file can't install bad minute" error. This is because crontab expects to have a minute value mentioned at the start of every line. In this example, we have used a script called backup.sh at the start of the Line hence it will throw bad minute error.

0 3 * * * /home/centos/example.sh
backup.sh

Scenario 4: You might get «errors in crontab file can’t install bad day-of-week»

I have also seen a scenario where sometimes Linux professionals uses some value in week section which is not expected hence started getting "errors in crontab file can't install bad day-of-week" error when try to save the file. One of the such instance I have shown below where week section expecting a value between 0 and 6 but instead 9 is mentioned which results in "bad day of the week" error.

* 4 0 * 9 /home/centos/example.sh

Scenario 5: You might get «errors in crontab file can’t install bad command»

There is another common mistake I have seen Linux Professionals or Beginners often doing is that they will some unexpected command or a command which is not set in $PATH which results into "errors in crontab file can't install bad command" error. One such instance I have shown here where jq command is not there in any of the Linux binary path hence it is not detecting this command. In these cases either you need to provide the complete path of the command or add the command path in $PATH so that system detects that command.

0/10 * * * * jq

Scenario 6: You might get «bad day-of-month errors in crontab file can’t install»

Finally I have also seen Linux professionals or beginners doing a mistake assuming month section as days of month section and will use any value greater that 12 resulting in "bad day-of-month errors in crontab file can't install" error. Here you need to be very careful in understanding the difference between days of the month and month of the year. Month of the year accepts value between 1 to 12 whereas days of the month accepts values between 1 to 31.

* * * 15 * /home/centos/example.sh

Popular Recommendations:-

Learn HTML Image Maps(v5) with Best Examples

Easy Steps to Install GCC(C and C++ Compiler) on CentOS 7

C# data types with Best Examples (.NET v4.7)

How to Transfer Files to an AWS EC2 Instance Using WinSCP in 3 Easy Steps

Learn HTML Tables(v5) with Best Examples

How to Install PHP on RedHat/CentOS 7 with Easy Steps

How to Install Ruby on Ubuntu 18.04 with Easy Steps

This is pretty clearly a bug, and it seems to affect Red Hat systems of a number of flavours. I’ve confirmed the behaviour you describe on CentOS 5, C6, Fedora 19, and Fedora 20.

For crontab entries of the form

30 a-b/c * * *  /bin/ls

it seems that if there exists no positive integer n for which a+nc is in the range [24,b], the invalidity check for the final hour (b) is ineffective. That is, you can write gibberish as long as the OS doesn’t actually have to do anything about it; if you specify a range and spacing such that it would actually trigger a job at an invalid hour (which includes 24) then crontab complains.

I’ve just persuaded my F20 system to accept the crontab entry

30 6-33/16 * * *  /bin/ls

which is insane by any standards. Similarly, 30 2-33/14 * * * /bin/ls and 30 1-33/16 * * * /bin/ls both give the (desirable) bad hour error, while 30 2-27/14 * * * /bin/ls is valid.

Congratulations, Arun, I think you’ve found a bona fide bug in Red Hat’s crontab (it isn’t present on Ubuntu 12.04LTS, though that’s the only other system I have to hand for testing). Do you want to log it with with RH bugzilla, or shall I?

This is a common error

Context

You will encounter this error when you attempt to create or update
a crontab file that contains a syntax error.

What causes this error

Crontab files, while very simple, have a precise specification. Among other things, a crontab must:

• Start with a valid cron schedule, environment variable or comment on each line
• Contain an executable expression after the schedule
• End with a newline
• Include a username after the schedule for system-wide crontab files

When any syntax error occurs, cron will return the message errors in crontab file can't install.

Fixing Errors in crontab file can’t install

This error message often includes a more specific problem that you can address, for example:

• Bad Minute Crontab Error
• Missing Newline Before EOF Error

If you are still stuck, review your local documentation for further guidance on crontab format. You can do this from your command line by running man 5 crontab

Cronitor automatically finds and monitors cron jobs.  Complete your setup in minutes.

Get Started Free