When anacron is installed but disabled (ie, no symlink exists in /etc/rc?.d),
then cron will fail to run the cronjobs in /etc/cron.{daily,weekly,monthly}.
This is because the default /etc/crontab file has lines such as the
following:

25 6    * * *   root    test -x /usr/sbin/anacron || run-parts
--report /etc/cron.daily

The above line checks whether anacron is executable; if so, it skips running
the jobs in /etc/cron.daily, EVEN IF anacron is not running and not scheduled
to run!!

The correct way to solve this problem is for cron to always run these scripts,
and let anacron (or other programs) fend for themselves. As it happens,
anacron installs cronjobs named '0anacron' in /etc/cron.
{daily,weekly,monthly}. When these scripts are run (by cron or anacron or
anything else), they update anacron's timestamps, thus informing anacron not
to re-run the scripts in that directory. In other words, the anacron package
"knows" about cron, and takes necessary action to avoid running scripts
twice; but cron does not know (nor should it) about anacron or other similar
programs.

Fix: replace the default /etc/crontab with the following:


# /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.
# This file also has a username field, 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    run-parts --report /etc/cron.hourly
25 6    * * *   root    run-parts --report /etc/cron.daily
47 6    * * 7   root    run-parts --report /etc/cron.weekly
52 6    1 * *   root    run-parts --report /etc/cron.monthly
#

I'm not sure how to deal with this on anacron's side. If people are
fiddling with the anacron <-> cron interaction, things are going to
break.

The method you're advocating would result in
cron.{daily,monthly,weekly}, being run twice if anacron starts before
cron. Anacron knows the jobs have been run, but cron doesn't.

On Thursday 18 August 2005 07:05 pm, Pascal Hakim wrote:
...

Good point; but my fix is still an improvement because it (1) reduces the
anacron <-> cron interaction, and (2) ensures that the jobs DO get done
(though possibly twice), instead of not running at all.

Furthermore, (3) jobs will be run twice sometimes, but probably not frequently
(in fact, only when the system has been off --at least during cron's
worktime-- for a few days in a row, as anacron wouldn't run otherwise), and
(4) those folks who insist on running both anacron and cron should expect
having their scripts run twice at times;-) (But folks who have both programs
installed, but only cron set to run, should not be penalized by never having
their jobs run, as in the current default setup.)

If you really wanted to avoid running jobs twice, the anacron <-> cron
interaction would have to increase. One improvement over the current default
would be to change the lines in /etc/crontab to the following form:

25 6    * * *   root    pidof /usr/sbin/anacron || run-parts
--report /etc/cron.daily

When cron starts (currently right after anacron starts), it reads this file,
sees that anacron is running (if pidof returns true), and so skips running
the scripts. But this is ugly: what if cron starts before anacron? what if
the anacrontab has been modified to not run the cronjobs, but something else
instead?

AFAICS, the only elegant solution would be to have timestamps for each job
(in some standard location), which are checked by both cron and anacron
before running the job, and are updated whenever the job is run.

I have to admit that personally, I'm more concerned about jobs running
twice than not at all. Your method helps people who go around and
disable by hand the package rather than un-installing, but makes it
worse for _everyone_ who has anacron installed and actually uses it.

The way it works now, this will actually happen everytime the power
status changes, or a machine is turned on before cron is schedule to run
those jobs.

(4) is almost everyone who has anacron installed. There's not much point
in using anacron without cron.

To be honest, I can't even find a use-case where you'd want to have
anacron installed, but disabled.

We can't keep going alont this way. What if someone modifies their
crontab to not run cron.daily? That's going to cause breakage too. We
have to decide a point past which it's not worth trying to fix the
problems that are caused by the users disabling system tools.

Your solution would also not work if the anacron wasn't running at the
time of the test.

I can't see this happening anytime soon. Javier?

Pasc

You're right. Debian doesn't seem to provide any officially sanctioned way to
disable startup services (like Red Hat's chkconfig). This being so, disabling
services "by hand" should probably be considered "unsupported behavior":
people who do it (like me) must suffer the consequences. (It would be nice if
a future release of Debian supported this, thru a chkconfig-like program.)

For now, it would be better if cron could determine whether anacron is being
started in the current runlevel, instead of relying on roundabout solutions
like 'test -x /usr/sbin/anacron' or 'pidof anacron'. (It seems that trying to
let cron be ignorant  of anacron won't work.) A possible solution would be
the following /etc/crontab (though I hate relying on an external script):

-----CUT-----
# /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.
# This file also has a username field, 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    run-parts --report /etc/cron.hourly
25 6    * * *   root    chkservice anacron || run-parts
--report /etc/cron.daily
47 6    * * 7   root    chkservice anacron || run-parts
--report /etc/cron.weekly
52 6    1 * *   root    chkservice anacron || run-parts
--report /etc/cron.monthly
#
-----CUT-----

Where chkservice is a script like this:

-----CUT-----
#!/bin/sh
if [ -z "$1" -o "$1" = -h -o "$1" = --help ]; then
        echo "Usage: chkservice [SERVICENAME]"
        echo "Check whether a service will run in the current runlevel"
else
        runlevels=(`/sbin/runlevel`)
        current=${runlevels[1]}
        if [ -e "/etc/rc$current.d/S??$1" ]; then
                exit 0
        else
                exit  1
        fi
fi
-----CUT-----

Note: cron apparently makes empty environments for its children. If you could
get the $RUNLEVEL env variable (mentioned by `man runlevel`) to be inherited,
you could eliminate chkservice and just use lines like this:

25 6    * * *   root    test [ -e "/etc/rc$RUNLEVEL.d/S??anacron" || run-parts
--report /etc/cron.daily

Summary: I understand why you have things the way they are. It's not perfect,
but it may well be the best. (Standard disclaimers about non-ideal world
apply.)

Hmmm. Debian does actually provide one, it's called update-rc.d although
you can shoot yourself in the foot if you don't use it properly. Most
users will want something like sysvconfig, sysv-rc-conf or file-rc, they
provide similar functionality to chkconfig.

I do dislike the need to rely on an external script (I actually wrote
one recently for a similar purpose, see #307929) and I don't think cron
should provide such a script even if it was needed for this. If a script
was needed, it would be best if sys-rv would include it.

Regards

Javier

I have a better solution. See bug #422775. If you apply the patch I
provided there, not only does it solve the bug described there, but it
also solves this one. Best of all, no negative side effects!

# Automatically generated email from bts, devscripts version 2.10.18.1
merge 464749 463656
# quacked the wrong one
unmerge 323710
merge 377603 323710

It seems that this is no longer an issue. Anacron installs a script,
/etc/cron.d/anacron. Even if anacron does not run at startup, such
as if /etc/rc?.d/*anacron was removed, cron will start anacron at
7:30am each morning.

Does this bug need to still be open?

severity 323710 wishlist
retitle 323710 Better cron - anacron interaction
thanks

Hello,

Joel Barker wrote:
have anacron installed, but disabled.

Also, /usr/share/doc/cron/README.anacron has always stated that when
both anacron and cron are installed, anacron is responsible for running
/etc/cron.d. This is therefore not a bug.

I'm leaving it open as a wishlist item, just in case a better solution
should develop over time.


Christian

Brandon wrote:

This won't work, because /etc/cron.d/anacron uses invoke-rc.d which
respects the runlevel policy in /etc/rc?.d (unless called with --force).


Christian