I'm confused about using the environment attribute of puppet's cron type. It seems like a weird place to set the PATH because then if I have multiple cron jobs I want to set up it seems like they will collide. Shouldn't it be set in a place that's global to all cron jobs for a user in addition to a specific one per cron job?
Ben, it makes perfect sense for cron jobs in my opinion. Consider this, as an example: there's a tool called Composer for dependency management in PHP, and say I'd like to schedule automatic updates to my dependencies via cron. If there are numerous dependencies and/or it just takes too long to update them all, the tool will timeout, and that's why it accepts COMPOSER_PROCESS_TIMEOUT environment variable. Thus by setting
environment => 'COMPOSER_PROCESS_TIMEOUT=2000',
I would effectively change the timeout for this particular case without touching anything else.
Hope it makes sense and cleared the air a bit.
I don't believe that the env variables will conflict with each other. The cron resource seems to set the variable at command execution time. so it shouldn't say set during other cron jobs.
eg.
# Puppet Name: pe-mcollective-metadata
0,15,30,45 * * * * /opt/puppet/sbin/refresh-mcollective-metadata
# Puppet Name: report_baseline
0 20 * * * PATH=/opt/puppet/bin:/bin:/usr/bin:/usr/sbin:/usr/local/bin /opt/puppet/bin/puppet inspect 1> /dev/null
So you can see here that the refresh-mcollective-metadata job does not have the PATH variable set when ran but the report_baseline job does.
Related
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.
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
This is more of an "general architecture" problem. If you have a cron job (or even a Windows scheduled task) running periodically, its somewhat simple to have it send you an email / text message that all is well, but how do I get informed when everything is NOT okay? Basically, if the job doesn't run at its scheduled time or Windows / linux has its own set of hangups that prevent the task from running...?
Just seeking thoughts of people who've faced this situation before and come up with interesting solutions...
A way I've done it in the past is to simply put at the top of each script (say, checkUsers.sh):
touch /tmp/lastrun/checkUsers.sh
then have another job that runs periodically that uses find to locate all those "marker" files in tmp/lastrun that are older than a day.
You can fiddle with the timings, having /tmp/lastrun/hour/ and tmp/lastrun/day/ to separate jobs that have different schedules.
Note that this won't catch scripts that have never run since they will never create the initial file for find-ing. To alleviate that, you can either:
create that file manually when creating the cron job (won't handle situations where someone inadvertently deletes the marker file); or
maintain a list of required marker files somewhere so that you can detect when they're missing as well as outdated.
And, if your cron job is not a script, put the touch directly into crontab:
0 4 * * * ( touch /tmp/lastrun/daily/checkUsers ; /usr/bin/checkUsers )
It's a lot easier to validate a simple find script than to validate every one of your cron jobs.