Anacron Jobs on a CentOS 7 Server
-
It's all in the anacron config file:
# /etc/anacrontab: configuration file for anacron # See anacron(8) and anacrontab(5) for details. SHELL=/bin/sh PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root # the maximal random delay added to the base delay of the jobs RANDOM_DELAY=45 # the jobs will be started during the following hours only START_HOURS_RANGE=3-22 #period in days delay in minutes job-identifier command 1 5 cron.daily nice run-parts /etc/cron.daily 7 25 cron.weekly nice run-parts /etc/cron.weekly @monthly 45 cron.monthly nice run-parts /etc/cron.monthly -
the anacron man page says:
quote:
For each job, Anacron checks whether this job has been executed in the last n days, where n is the period specified for that job. If not, Anacron runs the job's shell command, after waiting for the number of minutes specified as the delay parameter.After the command exits, Anacron records the date in a special timestamp file for that job, so it can know when to execute it again. Only the date is used for the time calculations. The hour is not used.
-
It's partially random, and partial a "delay by days." It would vary based on factors such as "when the server was built."
-
@scottalanmiller it is not
it says anacron runs every 7 days. but which is the 7th day???? why friday not saturday? -
@scottalanmiller so I've built that server on a friday maybe... don't remember...
-
@matteo-nunziati said in Anacron Jobs on a CentOS 7 Server:
@scottalanmiller it is not
it says anacron runs every 7 days. but which is the 7th day???? why friday not saturday?Seven days after the process first kicks off
-
@matteo-nunziati said in Anacron Jobs on a CentOS 7 Server:
@scottalanmiller so I've built that server on a friday maybe... don't remember...
That's likely the case.
-
@scottalanmiller I can't imagine there is no way to force a proper restart an a given day-of-week. again: weird.
-
from the man page:
/var/spool/anacron
This directory is used by Anacron for storing timestamp files.let's check those files
-
@matteo-nunziati said in Anacron Jobs on a CentOS 7 Server:
@scottalanmiller I can't imagine there is no way to force a proper restart an a given day-of-week. again: weird.
Probably just the wrong tool for the job. There is already a tool specifically for that.
-
well yes, simply it sounds weird to me that an enterprise distro per default uses what is basically a fuzzy job scheduler.
forcing jobs via cron is trivial, but I was courious about the default behavior and the rational behind it. this is simply not the case on debian based distros.
Next time I will check on Suse. -
@matteo-nunziati said in Anacron Jobs on a CentOS 7 Server:
well yes, simply it sounds weird to me that an enterprise distro per default uses what is basically a fuzzy job scheduler.
What makes it "by default?" When I use it "by default" it doesn't do that for me
It uses a strict scheduler. I have to go into the lesser known intentionally fuzzy scheduler to get the fuzzy system. -
AFAIK, the purpose behind the daily, weekly, monthly tabs is specifically to be fuzzy. It would make no sense to me otherwise since we have a strict scheduler already. It would make efforts duplicated without benefit if it wasn't fuzzy. And it would then require additional configuration to get the functionality that it currently gets by de fault.
-
@scottalanmiller it is default because in the default install the crontab is empty and cron.daily, cron.weekly etc.. are all delegated to anacron. And these folders are already populated with distro "native" jobs, which run basically at random days, depending on when you have installed the machine.
It is counter intuitive to me: they can run, they are scheduled to run, but you can not control exactly in which day. weird.
In ubuntu I put scripts in daily/weekly and so and then I know when the trigger starts (ok neglect the fuzzification of delays) because anacron is declared in the crontab.This is not the case with centos.
I find the folders really useful to collect scripts I want to run at given time deltas (e.g. backups...) I'm not used to set a crontab line for each job, as I tend to collect jobs on daily or weekly intervals.
It is a non issue but still a strange default. -
@matteo-nunziati said in Anacron Jobs on a CentOS 7 Server:
@scottalanmiller it is default because in the default install the crontab is empty and cron.daily, cron.weekly etc.. are all delegated to anacron. And these folders are already populated with distro "native" jobs, which run basically at random days, depending on when you have installed the machine.
I don't agree that that makes one default and one not. When you as a user run the crontab command, it does not give you those. Those are relegated for manual administration work. That they are prepopulated fuzzy tasks is because those tasks are supposed to be fuzzy by default. If they were specific, they'd have to choose specific times for them which would be unnecessarily odd. For putting in your own jobs, the user crontab is definitely considered the default or standard path for that. It is empty because the system does not do "specifically timed maintenance" because it wouldn't know when to do it.
-
@matteo-nunziati said in Anacron Jobs on a CentOS 7 Server:
I find the folders really useful to collect script I want to run at given time deltas (e.g. backups...) I'm not used to set a crontab line for each job, as I tend to collect jobs on daily or weekly intervals.
It is a non issue but still a strange default.I feel the opposite, Ubuntu seems strange to have two systems that overlap. Why would they do that? Seems very silly. You already have places for things, why have two of them?
-
sorry I've badly worded it.
In ubuntu/debian they per default schedule cron.{daily,weekly,monthly} in crontab and they run at specific days/weeks.
anacron is not there. you have to install it. it is not the default, and jumps in only if you install it!utente@debian:/etc$ cat crontab
#/etc/crontab: system-wide crontab
#Unlike any other crontab you don't have to run the `crontab'
#command to install the new version when you edit this file
#and files in /etc/cron.d. These files also have username fields,
#that none of the other crontabs do.SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin#m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )by default debian is deterministic while centos is fuzzy. while in either case the distro default makes your scripts run, their approach is different.
-
I see what you mean, that makes more sense then.
-
@scottalanmiller said in Anacron Jobs on a CentOS 7 Server:
I see what you mean, that makes more sense then.
That Debian setup is designed to crash update servers. Example. Every Debian system on the planet at 5 o'clock on Friday is going to go try to f***ing update.
-
Real example, I use Yum-cron.
Because of the fuzziness I don't wake up every Tuesday morning to 50 emails stating servers of updated
