Why does crontab not run

If you access files in your program, you'll need to take this into account if you use relative paths, or preferably just use fully-qualified paths everywhere, and save everyone a whole lot of confusion. Cron generally requires that commands are terminated with a new line. Edit your crontab; go to the end of the line which contains the last command and insert a new line press enter. A user formatted crontab does not include a username in the 6th position of a row, while a system formatted crontab includes the username and runs the command as that user.

If your date is recently changed by a user or system update, timezone or other, then crontab will start behaving erratically and exhibit bizarre bugs, sometimes working, sometimes not. This is crontab's attempt to try to "do what you want" when the time changes out from underneath it. The "minute" field will become ineffective after the hour is changed. In this scenario, only asterisks would be accepted. Restart cron and try it again without connecting to the internet so the date doesn't have a chance to reset to one of the time servers.

This is particularly intrusive when using the date command. Be sure to escape the percent signs. It's not recommended to run sudo commands in a cron job, so if you're trying to run a sudo command in a user's cron, try moving that command to root's cron and remove sudo from the command.

The last one hurts regularly unsuspecting users; in particular any script in one of these folders named whatever. In my experience, this particular point has been by far the most frequent reason for a non-executing cronjob on Debian and derivatives. If your cronjobs stop working, check that your password hasnt expired. Cron is all things considered a very basic scheduler and the syntax does not easily allow an administrator to formulate slightly more uncommon schedules.

Consider the following job which commonly would be explained to "run command every 5 minutes" :. Rather than a single cron job, create multiple batches that combined result in the desired schedule. For instance to run a batch every 40 minutes , , , etc. Rather than running your batch every 7 minutes, which is a difficult schedule to break down in multiple batches, simply run it every 10 minutes instead.

Start your batches more frequently but prevent multiple batches from running concurrently. Instead, think differently and create a cronjob that will fail gracefully when a previous run has not finished yet, but which will run otherwise. Start your batches more frequently but exit gracefully when the conditions are not right. Since cron syntax is limited you may decide to place more complex conditions and logic in the batch job itself or in a wrapper script around the existing batch job.

That allows you to utilize the advanced capabilities of your favorite scripting languages, to comment your code and will prevent hard-to-read constructs in the crontab entry itself. A different, but similar problem would to schedule a batch to run on the first Monday of every month or the second Wednesday etc. Simply schedule the batch to run every Monday and exit when date is neither between the 1 st or 7 th and the day of the week is not Monday.

If your needs are complex you might consider using a more advanced product that is designed to run complex schedules distributed over multiple servers and that supports triggers, job dependencies, error handling, retries and retry monitoring etc. Only after you can sleep well as all will be sent to your root's mail instead of just logged.

Adding my answer from here for completeness, and adding another potentially helpful resource:. A frequent problem users make with crontab entries is that they forget that cron runs in a different environment than they do as a logged-in user. The command runs perfectly from his command line. The user then adds that command to his crontab , but finds this does not work:.

The reason for the failure in this case is that. That is, the environment is different! The PATH is part of the environment , and it is usually different for the cron user.

A simple solution to this particular problem is to give the cron user a complete path specification in the crontab entry:. In some instances, we may need to know the complete environment specification for cron on our system or we may just be curious. What is the environment for the cron user, and how is it different from ours?

Further, we may need to know the environment for another cron user - root for example This thing should especially be taken care of while writing Cron jobs. Try running your desired script through the terminal to figure out if there are some issues with your script or fail only because of Crontab. In this article, we did an open-ended discussion on the various issues that can cause your Crontab to fail.

After digging deeper into those causes, we shared with you some of the most common and quick methods of troubleshooting these issues for fixing your Crontab immediately. Karim Buzdar holds a degree in telecommunication engineering and holds several sysadmin certifications. As an IT engineer and technical author, he writes for various web sites.

He blogs at LinuxWays. We all know that Cron or Crontab works as the best job scheduler for the Linux-based system. If you need more control over the environment, maybe run bare X11 without a desktop environment or window manager at all, and just run your script instead. Or in some cases, maybe replace the X11 login manager "greeter" with something custom built. Copying my answer for a duplicated question here. Another solution would be to specify an interpreter in the script file, make it executable, and call the script itself in your crontab:.

Sometimes the command that cron needs to run is in a directory where cron has no access, typically on systems where users' home directories' permissions are and the command is in that directory. How are we doing? Please help us improve Stack Overflow. Take our short survey. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams?

Collectives on Stack Overflow. Learn more. CronJob not running Ask Question. Asked 7 years, 7 months ago. Active 2 months ago. Viewed k times. Improve this question. Gopal Chitalia 2 2 silver badges 16 16 bronze badges. You should specify the path in full to avoid that dependency. Add a comment. Active Oldest Votes.

My cronjob doesn't run?! Here's a checklist guide to debug not running cronjobs: Is the Cron daemon running? Run ps ax grep cron and look for cron. Debian: service cron start or service cron restart Is cron working?

See below. You obviously need to have write access to the file you are redirecting the output to. Check if the script has an error, by doing a dry run on the CLI When testing your command, test as the user whose crontab you are editing, which might not be your login or root Can cron run your job?

If you are trying to figure out why something failed, the error messages will be visible in this file. Read it and understand it. Still not working? When you exit the editor, the modified crontab is installed automatically. Improve this answer. Milind Singh 4 4 silver badges 21 21 bronze badges. Jens A. Koch Jens A. You can always use the cron daemon services if you need to conduct specific time-bound functions.

What if your crontab stops operating at times? You may confuse yourself while finding out the reason behind this problem. In such a case, you will also try out all of the potential solutions. Please do not go for these options because, in this article, we will provide you some original methods for troubleshooting your crontab. Why is crontab not working in your system?

Crontab might fail for a variety of reasons: The first reason is that your cron daemon might not be working for any reason, resulting in your crontab failing.