Bug#752376: Bug#758034: apticron: ok to Depend on cron-daemon rather than cron?

Alexandre Detiste alexandre.detiste at gmail.com
Mon Sep 1 16:45:38 BST 2014


> > Then, the file /etc/crontab would then not contains theses standard "boilerplate" lines anymore
> >> 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 )
> > and will be empty by default.
> Uh? I'm not sure I understand you here - would it be only with 
> systemd-cron, or is systemd itself taking over anacron?
> If I'm using another cron implementation, I will still need those lines, 
> right?

/etc/crontab is not provided by base-files or something like that;
it has to be provided by the package provided cron functionality .

On a systemd using classic cron I get this:
pi at raspberrypi ~ $ dpkg -S /etc/crontab 
cron: /etc/crontab

A new systemd-cron + generator package would provide an empty file.
It would also "Conflicts:" with anacron to avoid double execution.

The anacron behaviour could toggled back-on by adding a file like that
	/etc/systemd/system/cron-monthly.timer.d/persistent.conf 
	[Timer]
	Persistent=true
that would be created by debconf.

> Imho systemd-cron should stop providing cron-daemon until "sudo apt-get 
> install systemd-cron" results in a system with the crontab generator 
> installed and working, but I'm probably biased against systemd :)

You're absolutely right.

But, I'm not maintainer for systemd-cron !
Anyone with right access can still right away remove the "Provides:cron-daemon" if they like.
I can still for myself build a dummy cron with equivs if I like.

I was waiting to see if systemd > 212 would be in Jessie
before going further and wasting my time 
coming with a proposal.

> Btw, I was thinking that there's another possible solution to this bug: 
> since /etc/cron.d/apticron runs every hour at some "urandom" minute, and 
> checks a timestamp file to make sure it's not running more than once per 
> day, couldn't it just run from /etc/cron.hourly?
>
> That should work even under systemd-cron, and it could __possibly__ be 
> combined with a couple of additions to the --cron option:
> - sleep a random amount of time, up to an hour (since cron.hourly runs 
> at a fixed minute every hor)
> - flock(1) a file in /var/lock, to make sure there can never be two 
> instances running (I don't remember when debian switched to /run/lock, 
> so/var/lock should be safer)

Under systemd, when using a native timer & service (not /etc/cron*)
all of this is a one-liner: "AccuracySec=1h" 
http://www.freedesktop.org/software/systemd/man/systemd.timer.html

..but it's not realistic at all to manually convert all jobs for Jessie;
so the generator is a better option.




More information about the Pkg-systemd-maintainers mailing list