I am building a unix package in which there is a script, according to the client requirements, script should run only once (not on daily basis). I am not sure how will it work?
I mean, do i need to schedule it ? if yes , then I could not find any cron command for it.
If no, then how will script get execute when package is being installed?
Cron is used for repetitive executions of the same command or script. If you look for a way to schedule an only once script run i would suggest you to use "at" command
Schedule script to run in 10minutes from now:
at now +10 minutes
sh <path_to_my_script>
Then ctrl+d to save
Instead of minutes you can use hours|days|weeks and so on. For reference https://linux.die.net/man/1/at
List queued jobs:
atq
To remove a given scheduled job:
atrm <job_id>
Note: please ensure you have previleges to run the the scheduled script or run it with sudo.
There are two general ways to schedule a task in Unix/Linux:
cron is useful for repeatable tasks.
at is useful for single tasks.
So, in your case, I'd use at for schedule your task.
If it is only once at installing package, you do not need cron at all, just make the user execute it. Lets say you instruct the user to execute something like ./install, and include the script and that's it.
But as someone previously said, first define what is the meaning of once.
Regards.
Related
I can't seem to get my script to run in parallel every minute via cron on Ubuntu 14.
I have created a cron job which executes every minute. The cron job executes a script that runs much longer than a minute. When a minute expires it seems the new cron execution overwrites the previous execution. Is this correct? Any ideas welcomed.
I need concurrent independent running jobs. The cron job runs a script which queries a mysql database. The idea is to poll a db- if yes execute script in its own process.
cron will not stop a previous execution of a process to start a new one. cron will simply kick off the new process even though the old process is still running.
If you need cron to terminate the previous process, you'll need to modify your script to handle that itself.
You need a locking mechanism to identify that the script is already running.
There are several ways of doing this but you need to be careful to use an atomic method.
I use lock directories as creating a directory is guaranteed to be atomic -
LOCKDIR=/tmp/myproc.lock
if ! mkdir $LOCKDIR >/dev/null 2>&1
then
print -u2 "Processing already running - terminating"
exit 1
fi
trap "rm -rf $LOCKDIR" EXIT
This is a common occurrence. Try adding a check in your script to see if a lockfile already exists. If it does, exit. If not, continue.
Cronjobs are not overrun. They do however have the possibility of overlapping. Unless your script explicitly kills any pre-existing process, it shouldn't be able to stop the previously running script.
However, introducing the concept of lockfiles will save you from all these confusions altogether.
Technically speaking, what is the difference between a cron, crontab, and cronjob?
From what I can gather, cron is the utility on the server, crontab is a file which contains the time intervals and commands, and cronjob is the actual command (or file/script which contains commands).
Is this correct?
cron is the name of the tool, crontab is generally the file that lists the jobs that cron will be executing, and those jobs are, surprise surprise, cronjobs.
Cron: Cron comes from chron, the Greek prefix for ‘time’. Cron is a daemon which runs at the times of system boot.
Crontab:
Crontab (CRON TABle) is a file which contains the schedule of cron entries to be run and at specified times. File location varies by operating systems.
Cron job or cron schedule:
Cron job or cron schedule is a specific set of execution instructions specifying day, time and command to execute. crontab can have multiple execution statements.
Reference: http://www.adminschoice.com/crontab-quick-reference
I am putting this here so I can find it again when I need it and to have a place for additional input from other people. I have read several pages on this topic (some contradictory, some with examples that do not work) So here is my current understanding:
There are 2 Daemons in Linux to schedule future tasks "cron" and "at"
The idea behind "at" is to be a tool to run one off (single) future jobs, there is a variation of "at" called "batch" which will run the jobs only if system resources are almost idle
"cron" is usually used by configuring the Chronological Table or (crontab), the idea behind the cron system is to set up jobs that need to be run repetitively in the future. While most cron jobs are set using the crontab command, the cron command can be used directly to do a one off. There is a alternative to crontab called anacron which can be used if your system is not on 24/7.
cron is a Unix, Solaris utility that allows tasks to be automatically run in the background at regular intervals by the cron daemon.
Crontab file A crontab file has five fields for specifying day, date and time followed by the command to be run at that interval.
I have set a cron job for a file for every 6 hours. The file may run for 4hours.
If i set cron for another file , will it affect the previous one which may run for 4hours?
No. If the job is not working on same resources, it wont conflict even if it's running simultaneously.
The cron daemon doesn't check to see if anything else by the same name is running, if that is what you mean, so cron will not care. However, if your script creates temporary files, for example, without using helper-tools like "mktemp" they could conflict with each other - so that will depend how well written your script is.
I'm doing a research project that requires I monitor cron jobs on a Ubuntu Linux system. I have collected data about the jobs' tasks and when they are started, I just don't know of a way to monitor how long they take to finish running.
I could calculate the time of finishing the task minus starting it with something like this but that would require doing that on the Shell scripts of each cron job. That's not necessarily difficult by any means but it seems a little silly that cron wouldn't in some way log this, so I'm trying to find an easier way :P
tl;dr Figure out time cron jobs take from start to finish
You could just put time in front of your crontabs, and if you're getting notifications about cron script outputs, it'll get sent to you.
For example, if you had:
0 1,13 * * * /maint/run_webalizer.sh
add time in front
0 1,13 * * * time /maint/run_webalizer.sh
and you'll get some output that looks like (the "real" is the time you want):
real 3m1.255s
user 0m37.890s
sys 0m3.492s
If you don't get cron notifications, you can just pipe the output to a file.
man time. Maybe you can create a wrapper and tell Cron to use it as your "shell" or something like that.
Cronitor (https://cronitor.io) is a tool I built exactly for this purpose. It uses http requests to record the start and end of your jobs.
You'll be notified if your job doesn't run on schedule, or if it runs for too long/too short. You can also configure it to send alerts to you via email, sms, but also Slack, Hipchat, Pagerduty and others.
I use the Jenkins CI to do this via its external-monitor-job plugin. Jenkins can track start and end times, track overall execution time over time, save the output of all jobs it tracks, and present success/failure conditions graphically.
https://wiki.jenkins-ci.org/display/JENKINS/Monitoring+external+jobs
Suppose if i have cron tasks running every minute. And if each time, that task takes more than one minute to run, what will happen. Will the next cron wait for the first cron or will it run without any checks.
I want to run a cron task every minute and I don't over lapping cron tasks like that in case of a long running task/situation.
please help.
It depends on what you run. If it's your own script, you can implement a locking/lock checking mechanism to avoid running duplicates.
But that's not cron's job.
Yes, cron will go ahead and start your 1+ minute-running process every minute until something crashes.
You'll want to put a lock of some sort into your job if you can to basically do this at start-up:
if not get_lock()
print "Another process is running"
exit
This, of course, assumes that you own the code running. If you're running a command that you didn't code, then I'd recommend building a shell wrapper that implements the above pseudocoded logic where get_lock() will see if another process like this one is running.
As others have mentioned, CRON will run your script every minute regardless of whether another instance of your script is still running.
If you want to avoid this and don't fancy implementing your own locking mechanism then you could try using a CRON alternative called The Fat Controller which is a daemon that will continually re-run scripts. You can optionally specify an interval between runs and also optionally specify a maximum execution time so if a script goes AWOL then it can be killed.
There's some use cases and more information on the website:
http://fat-controller.sourceforge.net/