Anacron Jobs on a CentOS 7 Server



  • My centos 7 machine has a number of cron.{daily,weekly,monthly} scheduled works.
    by default crontab in Centos 7 is empty and cron jobs are executed by anacron according to its conf file.
    This is ok for me, but one thing I'm missing is where the anacron definition of week/month is located.

    I mean, e.g., that the weekly jobs are run on friday. This is ok for me but I've searched a bit around and I've not found any setting for move the weekly execution to -say- Sunday.

    On debian like distros the setup is slightly differtent and you can easily adjust the execution day in crontab. Everyone is just saying: put your cron.weekly job in crontab even on centos and avoid anacron to run the job. But this is not the solution I'm searching for.

    any hints?!



  • @matteo-nunziati said in anacron jobs on a centos 7.x server:

    Everyone is just saying: put your cron.weekly job in crontab even on centos and avoid anacron to run the job. But this is not the solution I'm searching for.

    That's what I do 🙂



  • @scottalanmiller that's ok, but this doesn't answer the question: where -by jove- anacron+systemd hide the exact execution day for a weekly job?!



  • @matteo-nunziati said in Anacron Jobs on a CentOS 7 Server:

    @scottalanmiller that's ok, but this doesn't answer the question: where -by jove- anacron+systemd hide the exact execution day for a weekly job?!

    I assume you've found nothing in the config files under /etc/cron and/or /etc/anacron? Do the man pages say anything about a setting you can add in a config file?



  • the cron file is empty by default.
    anacron conf file to not declare when the week finish/start! even the anacron man page to not declare anything!
    Again, on debian cron explicitly raises an anacron job on sunday, not here on centos. weird.



  • 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



  • @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 😉