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.
Related
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.
This is probably stupidly obvious beginner question, but somehow I can't find the answer.
On my debian box, I have a script in /etc/cron.d. It executes every once in a while, but I can't find the schedule or initiator. I've tried looking at all users cron tabs, as described here, but no user has a script that runs the cron.d. I've looked at /etc/crontab, which holds the scripts for cron.daily, monthly and hourly, but not cron.d.
Where is this schedule held?
From the output of man cron,
Support for /etc/cron.d is included in the cron daemon itself,
which handles this location as the system-wide crontab spool. This
directory can contain any file defining tasks following the
format used in /etc/crontab, i.e. unlike the user cron spool, these
files must provide the username to run the task as in the task
definition.
This implies that the file inside /etc/cron.d should not be a script, but rather a configuration file that looks similar to /etc/crontab. It will carry its own scheduling information, the same way that /etc/crontab does. In particular, the format should look like:
# m h dom mon dow user command
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.