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

Lorenzo lory.fulgi at infinito.it
Mon Sep 1 18:13:30 BST 2014


On 09/01/2014 05:45 PM, Alexandre Detiste wrote:
>>> 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.
Ok, thanks.

>
>> 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
I don't know if it's neat or scary :)
>
> ..but it's not realistic at all to manually convert all jobs for Jessie;
> so the generator is a better option.
>
I'm 120% with you on this.




More information about the Pkg-systemd-maintainers mailing list