Rarely, I have run into commands that require user input. I have added them when inexperienced users would be editing a crontab. There are headers available which help with getting the scheduling parameters right. Using the file provides a backup of what the crontab should be, and allows temporary edits (the only time I use crontab -e) to be backed out automatically. This will eventually correct cases where the wrong crontab is loaded on the wrong server. If the directory is network-shared, then I often use crontab.$(hostname) as the name of the file. Some systems require the running crontab in the command and specifying the file. The reload command above relies on an executable crontab with a bang path running crontab. This is reloaded daily from a crontab entry like: #!/usr/bin/crontab It is commented throughout and ends with the line # EOF. This can be recovered from the existing crontab using crontab -l if it gets clobbered. Other environment variables can also be missing.Ĭlobbering an existing crontab entirely has caused me problems. This also affects scripts using non-standard commands. These directories usually don't have the desired command. The default path is usually /bin:/usr/bin so only standard commands will run. Using unqualified paths have also caused problems.
I have also run across issues with lists like 1-5 or 1,3,5.
This is a very useful option but not universally available. If your work with different platforms using unsupported options such as 2/3 in time specifications can also cause failures. If you are not sure, check your cron schedules online at. Specific dates are usually a problem as we rarely use them * * 3 1 * is not March 1st. Day of the week for jobs after midnight also gets confused M-F is 2-6 after midnight, not 1-5. It takes practice to specify a job scheduled for 11:15 pm as 15 23 * * * instead of * * 11 15 * or 11 15 * * *. The most frequent reason I have seen cron fail in an incorrectly stated schedule. PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binġ5 1 * * * backupscript -incremental /home /root You can also set the PATH variable in the crontab file, which will apply to all cron jobs. You'd have to go through the whole script replacing /opt/someApp/bin with /opt/someAppv2.2/bin instead of just doing a small edit on the first line of the script. Consider what happens if you want to run your script on a different system, and on that system, the command is in /opt/someAppv2.2/bin instead. Some prefer to just use absolute paths to all the commands instead. PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin To get around that, just set your own PATH variable at the top of the script. It's worth noting that variables from /etc/environment will be passed on to cron jobs, just not the variables cron specifically sets itself, such as PATH. Maybe your cron script uses the command somecommand found in /opt/someApp/bin, which you've added to PATH in /etc/environment? cron ignores PATH from that file, so runnning somecommand from your script will fail when run with cron, but work when run in a terminal. Now compare the contents of /tmp/env.output with the output of env run in your regular terminal.Ī common "gotcha" here is the PATH environment variable being different. Wait for /tmp/env.output to be created, then remove the job again. To see the difference, add a dummy job like this: * * * * * env > /tmp/env.output Cron passes a minimal set of environment variables to your jobs.
0 kommentar(er)
