I wanted to create a crontab file with schedule but do not want it to run.
How can I achieve this?
I created a crontab file using crontab -e, added the job. This has started running. I do not want this to run as the job should be scheduled ad hoc.
I wanted to prepare and keep and use the schedule on ad hoc.
You can comment your schedule line out with a leading #, and remove the comment marker again when you want it to run.
http://man7.org/linux/man-pages/man5/crontab.5.html
You could test for a file to be present and if it does it'll execute your task:
5 * * * * user test -f /var/lock/subsys/myfile && /home/user/backup.sh
Thus when you are ready. You just
touch /var/lock/subsys/myfile
and the script starts within the next five minutes.
But you have to make sure to remove the lock file afterwards.
Related
Background
I need to add a cron job to a server that has a bunch of other cron jobs on it. I have never done this before so I want to make sure I do it without affecting any other cron jobs.
I read in a tutorial here
You can add more schedules the same way. Put all your different
schedules into a single crontab file. The first line should be your
MAILTO line, followed by each schedule/command on a separate line.
When you run "crontab crontab.txt" later, crontab will replace your
existing schedule with the schedules in your new crontab.txt.
It sounds like it will replace any cron jobs in that file but I want to be sure it does not overwrite all cron jobs and set the new schedule to the newest file installed.
Question
So to be clear. If I have existing cron jobs on a server and I create a new cron.txt file that has new cron jobs in it. Will it install the cron jobs in the new file and leave the existing cron jobs which are in other cron job files unchanged so they will continue to work as they have been?
Example
Runs everyday at 9:30am
NewCronJobs.txt
MAILTO=email#example.com
30 9 * * * /root/path/to/php/file/to/run/script.php >/dev/null
You should have your own crontab, so you should be able to modify it without messing up anybody else's jobs. Try this, in your terminal type
crontab -e
If you see cron jobs already listed, then do not change them. If not, then you are starting from a blank slate. Regardless of whether you see other cron jobs or not you can always add your task to the bottom or the current crontab file. Provided your php script is not faulty you will be able to test your cron job without adversely affecting anything on the server.
I'm trying to run some specific jobs at specific times during the day to capture particular data on my db during increments, and I currently have TONS of jobs that run perfectly fine, but these don't seem to run on there designated time, and I often times have to run them on my own.
Currently these are the scheduled times.
I PRESUME 9AM everyday. As I've checked everywhere and it appears correct syntax.
0 9 * * * bash /home/user/Desktop/CRON/OAK3/dw_3704255.sh
I PRESUME 1:30PM everyday. As I've checked everywhere and it appears correct syntax.
30 13 * * * bash /home/user/Desktop/CRON/OAK3/dw_3704278.sh
I PRESUME 6PM everyday. As I've checked everywhere and it appears correct syntax.
0 18 * * * bash /home/user/Desktop/CRON/OAK3/dw_3704286.sh
I PRESUME 10PM everyday. As I've checked everywhere and it appears correct syntax.
0 22 * * * bash /home/user/Desktop/CRON/OAK3/dw_3704294.sh
Now, I've tried changed changing the front zeros to 00, but the same result has occured. I recently changed to single zero, but I believe that's how I've originally had it.
I may just need a sanity check from outside perspective, because it appears right, but any insight would be appreciated. Thank you!
I'd assume the jobs will start running, but won't complete for some reason, making it look like they didn't start at all. This is often caused by an environment variable that's set in .profile - cron jobs won't execute .profile and won't have access to these variables.
I'd put a statement like
exec > /tmp/dw_3704255.log 2>&1
set -x
at the start of your dw_3704255.sh script; then you can check if the file appears at the time it should, and check its contents for a trace as well.
Also, i'd replace bash with /bin/bash to protect against weird PATH settings in the cron process, but i wouldn't assume this to be the cause of your current problem.
Please check the cron log
grep CRON /var/log/syslog
My product requires a cronjob processing for every message a user sends to another users. This cronjob gets added to the crontab on the server. Everything works fine. Now once the job is done, is there a way to remove the expired cronjob entry from crontab?
Since the number of messages are huge, my crontab keeps growing so I want to clean up the old job entries. Any neat way of achieving it?
At least in most Linux distributions there is a crontab command that allows you to fetch and set the contents for the user's crontab. You can use it as such:
crontab -l > myfile
... edit the file (removing the entry)
crontab myfile
However this is clunky and error-prone. A better way is to wrap your job in a script that checks for a condition (e.g. a flag file) to decide whether to run the underlying logic and manipulate this flag file instead.
This question may sound incredibly stupid, but if I don't ask I'll never know...
All the tasks setting I do is always by using "crontab". I heard the term "cronjob" somewhere. Is it another tool or just a name for something in "crontab"?
A cronjob is just a single entry in a crontab, that's all.
The cronjob is what you put into your crontab.
crontab is the actual command line entry that is used to kick off a cron job (not cronjob).
to create a cron job, do the following
crontab -e
And then fill in the cron syntax for the scripts/programs you want to run at a specific "cron'ed" interval.
Try playing in the cron sandbox - lets you try out combinations of crontab timing values and gives you a list of when the job would run. www.dataphyx.com
I have a crontab setup to run a perl script every hour, at 5 minutes past the hour (so 2:05, 3:05, 10:05, etc.):
5 * * * * perl /abs/path/to/my/script.pl >> /abs/path/two/my/script-log.txt 2>&1
As you can see, it's also redirecting both STDOUT and STDERR to the same log file.
I've been asked to refactor either the Perl script, the crontab entry, or to add any new code/scripts necessary so that every night, at midnight, the script-log.txt gets cleared/flushed/emptied.
That is, every night, at midnight, if script-log.txt has 20MB of text in it, to clean it out so that it now has nothing (0bytes) in it, and then at 12:05 AM the crontab would kick back in, run script.pl, and start adding more text to the same script-log.txt log file.
It would be enormously easier if there was a way to modify the crontab entry with some Linux/Perl magic to set up such a "daily rolling log file". In a worst-case scenario, we can always write a new script to purge script-log.txt and cron it to run at midnight. But my higher-ups would greatly prefer to not have yet-another cron job, and are looking for a way to do this from the entry itself (if possible).
In reality, we have dozens of entries that work like this, and so the problem with writing "purging script" and cronning it to run at midnight is that we'll constantly be updating the purging script as we add/delete other scripts that generate these kinds of log files. Thus, if we can set such purging up at the entry level, each cron entry cleans itself. Thanks for any insight/pointers/suggestions in advance.
You might want to look into logrotate.