On Sat, 23 Feb 2019 12:55:39 -0800 Russ Allbery <rra@debian.org> wrote: > Laurent Bigonville <bigon@debian.org> writes: > > > So my idea was, we can either force the installation of anacron again (I > > wonder if we shouldn't do that for buster anyway) or we go forward and > > we move to use systemd timers instead of cron (which allows proper > > process tracking just like any other service). > > No objections to adding an experimental tag to track this, but just to > warn (mostly for the record in the bug): converting a cron job to a > systemd timer is not trivial, nor is providing the logic that ensures the > job then doesn't run twice (since the cron job can't be removed because > the host may not be using systemd). We don't have good helpers for this > yet, so it requires some careful thought to make this work properly. Isn't a [ -d /run/systemd/system ] || "do stuff" or the equivalent [ -d /run/systemd/systemd ] && exit 0 rather trivial to implement in the cron job? Sure, this would needlessly start cron jobs which are basically nops, but mid to long term I would say the goal should be anyway to no longer install cron (and anacron ftm) at all. Do you think this is an unrealistic goal? If not, I'd rather spend time updating packages to ship native timers instead of trying to extend our various cron implementations. I also agree that we should get timers into policy at some point. Regarding the lintian check, should we enforce a strict name matching or not? A /etc/cron.d/foo cron job could have an equivalent /lib/systemd/system/bar.timer (there is no override mechanism as for sysv init scripts after all). Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
Attachment:
signature.asc
Description: OpenPGP digital signature