A helpful tidbit I ran across about using crontab.
If each of your cron jobs do not appear on a single line in the crontab text file, you’ll get an error like this:
/tmp/crontab.XXXXXX.crontab":1: bad minute errors in crontab file, can't install. Do you want to retry the same edit?
This problem most often occurs because you’re using a text editor, such as pico, that fakes word wrapping by adding a newline when it reaches a certain column position.
Crontab delimits jobs with line breaks (newlines). Each job occupies one line. Therefore, if crontab sees anything other than an integer in the first column of a line, it throws the “bad minute” error, since the minute argument is the first one crontab encounters.
The simple fix is to go to delete the line breaks added by pico / your *nix editor. You can most easily do that by putting your cursor on the first character of each extra line, then hit the backspace key until that line is joined back up with the previous one, and repeating the process until your entire cron command is on one line.
Doug, thank you so much! I was getting completely mystified by that “bad minute” thing, and visited 3 kinds of bad advice on it before finding the right answer – yours!
Thanks for this!
Muchas gracias, problema resuelto.
Excelente explicación.
Simple solution TY
Thank you. You solved my problem.
It is important to note that another possible reason for this error exists. We are setting variables at the top of our chrontab. When the line reads:
HOME=/
it works fine, but when the line reads
HOME=
it fails with bad minutes error. I know, you’re asking “Why would you declare a variable without populating it?” It was a mistake. Anyway, hope that helps someone.
If the cron file is created in windows you get a LF+CR att the end of the lines. It should be just LF, the Unix way. Run dos2unix to fix this
Thank you very much for this simple and very powerful solution.
Also found today, using nano to edit crontab is a bad idea as it has an ‘autowrap’ option (default on) which will break lines at 80 chars. use ESC+W to turn it off
Thanks!
Thanks for the fix. Just want to let others know that this even happens in the Nano text editor which is what gets triggered when using the following command on a Centos5 linux in a command window:
cronjob -e
Thanks!
If I had to Google this solution from 9 years ago, you’d think they’d change nano & pico to work with crontab files.