Anacron Jobs on a CentOS 7 Server
-
@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 -
@JaredBusch well never considered the workload on servers. I don't know how they manage it! maybe not so many use unattended upgraqdes in debian.
-
@JaredBusch that's exactly the opposite for me: I prefer a billion of mails to check altogether rather that fuzziness.
-
@matteo-nunziati said in Anacron Jobs on a CentOS 7 Server:
@JaredBusch well never considered the workload on servers. I don't know how they manage it! maybe not so many use unattended upgraqdes in debian.
I definitely feel like Ubuntu users don't keep their systems as up to date
