ZNHOO Whatever you are, be a good one!

Cronie and Anacron

cron automates taks sheduling at specific time. There are many different implementations of which I choose cronie with anacron USE flag enabled. It accomplishes this task by waking up every minute and checking to see if there are any cron-jobs to run in any of the user crontabs.

It is basically for servers that won't shutdown. Sheduled tasks would not be ran if the machine is powered off at the exact sheduled time. anacron however, does not assume the machine is running continuously. anacron usually relies on another cron daemon (i.e. cronie) and executes commands at intervals specified in day. It will run missed jobs upon startup.

root@tux ~ # echo 'sys-process/cronie anacron' > /etc/portage/package.use/cronie (opt)
root@tux ~ # emerge -avt virtual/cron
root@tux ~ # rc-update add cronie default

cronie has built-in anacron feature that is optionally now.

cronie schedules locates in /etc/crontab and /etc/cron.d/, while anacron in /etc/anacrontab. Like most other cron daemons, cronie depends on sys-process/cronbase whose jobs in /etc/cron.{daily,hourly,weekly,monthly}. So we have three cron components, namely cronbase, cronie, and anacron which can be combined to meet our job schedule requirements.

All those above are system-wide schedules and we can manually edit those files. We define user schedules with crontab command:

root@tux ~ # crontab [ -u USER ] [ -l | -e | -r ]

crontab command does not handle system-wide schedules. Without explicit -u argument, it defaults to root account. It edits (or creates) file /var/spool/cron/conrtabs/${USER}. File name is the same as user account name. When executing commands under su you should always use the -u option.

The built-in anacron feature does not bring in command line to edit /etc/anacrontab. Like system-wide schedules, anacron schedules should be updated manually.

Let's have a look at the default system-wide schedules. In /etc/crontab, we found:

59  *  * * *    root    rm -f /var/spool/cron/lastrun/cron.hourly
9  3  * * *     root    rm -f /var/spool/cron/lastrun/cron.daily
19 4  * * 6     root    rm -f /var/spool/cron/lastrun/cron.weekly
29 5  1 * *     root    rm -f /var/spool/cron/lastrun/cron.monthly
*/10  *  * * *  root    test -x /usr/sbin/run-crons && /usr/sbin/run-crons
cronie daemon runs run-crons script (comes with cronbase) every 10 minutes. run-crons looks into */etc/cron.[hourly daily weekly monthly]* for scripts to be executed. For example, /etc/cron.daily/logrotate.

The schedules above gurantee jobs got ran even if the computer was off when they were scheduled to run. Details can be checken from run-crons script. Therefore, there is no need to enable anacron USE.

Specially, we found /etc/cron.hourly/0anacron script. That is to say:

cronie triggers cronbase's hourly job 0anacron.

At the tail of 0anacron, anacron -s handles schedules defined /etc/anacrontab. Different from cronie that schedules jobs at fixed time , anacron schedules to run jobs every other days (day, week, month).

*/etc/cron.[daily weekly monthly]* will be ran twice by cronie (run-crons) and anacron (run-parts) at different times, leading to possible double job executions.

Either remove anacron USE or comment out any overlapping entries from /etc/crontab or /etc/anacrontab.

Before a user can access to crontab, he must be in cron group by gpasswd -a username cron. Then we update */etc/cron.{allow, deny}:

# /etc/cron.deny
all

# /etc/cron.allow
username

With this setting, all users (except root) by default cannot access to crontab. We grant access by adding user name to cron.allow.

  1. arch wiki cron
  2. gentoo wiki cron
  3. bug 538864
  4. how cronie anacron hourly daily weekly work
  5. Cronie changes