Even if the job is logged there, any errors won't show up there. So it's helpful to log those separately. You're bound to thank me later ;. Your cronjob will fail at some point. A service such as Dead man's snitch will most certainly help you knowing when it failed. The premise is that you'll send a request to their service and if no request has been sent in the last X minutes, it will notify you that your cronjob likely failed and you need to check it out.
Having your crontab checked in with git is certainly helpful. If you're using dokku there is the helpful plugin supply-config that does almost that. There is an open PR that amends that gap.
Dokku documentation also have some helpful reminders on what to keep in mind when configuring a crontab. Easy fix to remove the 'v':. If you are accessing an account via SSH keys it is possible to login to the account but not notice that the password on the account is locked e.
If the system is using PAM and the account is locked, this can stop its cronjob from running. I've tested this on Solaris, but not on Ubuntu. To run a cron job inside the container, I used supervisor and ran cron -f , together with the other process. I was writing an install shell script that creates another script to purge old transaction data from a database. As a part of the task it had to configure daily cron job to run at an arbitrary time, when the database load was low.
My two gotchas:. Line written in a way crontab doesn't understand. It needs to be correctly written. Here's CrontabHowTo. Writing to cron via "crontab -e" with the username argument in a line. I've seen examples of users or sysadmins writing their shell scripts and not understanding why they don't automate.
So, why would you do the latter? Well, depending on how you want to set your permissions, this can become very convoluted. I've written scripts to automate tasks for users who don't understand the intricacies, or don't want to bother with the drudgery. By setting permissions to --x , I can make the script executable without them being able to read and perhaps accidentally change it. However, I might want to run this command with several others from one file thus making it easier to maintain but make sure file output is assigned the right owner.
Doing so at least in Ubuntu Sloppy, but it works. Building off what Aaron Peart mentioned about verbose mode, sometimes scripts not in verbose mode will initialize but not finish if the default behavior of an included command is to output a line or more to the screen once the proc starts.
For example, I wrote a backup script for our intranet which used curl, a utility that downloads or uploads files to remote servers, and is quite handy if you can only access said remote files through HTTP. I had to use the silent flag -s to tell it not to output any information, and write in my own code to handle if the file failed to download. Although you can define environment variables in your crontable, you're not in a shell script. So constructions like the following won't work:.
This is because variables are not interpreted in the crontable: all values are taken litterally. And this is the same if you omit the brackets. So your commands won't run, and your log files won't be written When a task is run within cron, stdin is closed.
Programs that act differently based on whether stdin is available or not will behave differently between the shell session and in cron. An example is the program goaccess for analysing web server log files. This does NOT work in cron:. In the shell this can be reproduced with. The fix for goaccess is to make it read the log from stdin instead of reading from the file, so the solution is to change the crontab entry to. Basically I had to run cron-config and answer the questions correctly.
There is a point where I was required to enter my Win7 user password for my 'User' account. From reading I did, it looks like this is a potential security issue but I am the only administrator on a single home network so I decided it was OK. In my case, just as for that commenter, it was the root user of a DigitalOcean box. Ubuntu Community Ask! Sign up to join this community. The best answers are voted up and rise to the top.
Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Learn more. Why crontab scripts are not working? Ask Question. Asked 10 years, 9 months ago. Active 1 year, 7 months ago. Viewed 1. There are numerous reasons for that: wrong crontab notation permissions problem environment variables This community wiki aims to aggregate the top reasons for crontab scripts not being executed as expected.
Improve this question. You must close crontab -e for the cron to take affect. For instance using vim I edit the file and use :w to write it but the job is not added to cron until I quit also. So I will not see the job until after I :q also. I think best way to debug cron is to check syslog and find the problems. In my case - the email was going to my SPAM folder, so Electricity outages — Josef Klimuk.
Please check this one askubuntu. Add a comment. Active Oldest Votes. Different environment Cron passes a minimal set of environment variables to your jobs. To get around that, just set your own PATH variable at the top of the script. You can also set the PATH variable in the crontab file, which will apply to all cron jobs. Improve this answer. I think I just fell for this, and newline at end It was actually sliiiightly different in my case. You can't guard against sysadmins making silly mistakes.
If you install a newer version of an interpreter that is not backwards compatible, I'd expect breakage regardless. The sane way to handle that is to install it as a different command. I still fail to see why it's a bad idea to use PATH though.
If you feel like discussing this further in a medium better suited for discussion, you'll find me in ubuntu and bash, among other channels, on irc. Show 18 more comments. Below is the relevant section in the man pages for this issue man crontab then skip to the end : Although cron requires that each entry in a crontab end in a newline character, neither the crontab command nor the cron daemon will detect this error. Instead, the crontab will appear to load normally.
However, the command will never run. The best choice is to ensure that your crontab has a blank line at the end. Seems to be fixed in Vixie cron: man crontab on Ubuntu If the last entry in a crontab is missing the newline, cron will consider the crontab at least partially broken and refuse to install it. The "newline" character is supposed to be a line termination character, so the final line in a text file is supposed to end in a newline character that doesn't get shown in the editor.
Vi and vim use the character correctly, and cron was built before the new editors started their odd behavior Hence playing it save and including a blank line. If you edit crontab using crontab -e it will check the syntax of the file before allowing a save, including a check for newline.
Chan-HoSuh, according to man page "cron requires that each entry in a crontab end in a newline character. Show 8 more comments. To fix it, we have to set the proper file permission for the script. In most of the cases, we should use shebang at the start of the script.
For example, if your script is written in Bash, try to use! This allow scripts and data files to be used as commands, hiding the details of their implementation from users and other programs, by removing the need to prefix scripts with their interpreter on the command line.
Another common issue is related to the environment variable. To troubleshoot, you can log the actual environment variables that loaded in the cron by having this simple command in cron table. These variables can be loaded directly by putting right before the command, for example:.
You can specify the shell at the begining of crontab. The Crontab Crontab cron table is a configuration file that specifies shell commands to run periodically on a given schedule. Why crontab scripts are not working? There are several reasons for that. Following is top 5 reason we might have 1.
0コメント