Bug#770440: debian-policy: policy should mention systemd timers
On Fri, 21 Nov 2014 10:30:13 +0100 Alexandre Detiste <alexandre.detiste@gmail.com> wrote:
> The policy should mention how to handle systemd native timers
> to avoid these kind of bugs in the future;
> when other packages will start shipping native timers.
>
> Here is the spirit of this change:
>
> +To maintaint compatability with SysV Init;
> +packages that ships native timers must also ship corresponding
> +crontabs. (/etc/cron.daily|weekly|monthly/) would remain unaffected.
> +
> +These cron jobs must then also ensure that systemd is not
> +currently running to avoid duplicate execution.
> +
> +A canonical way to both ensure that systemd is not currently running
> +and that package hasn't be removed would be:
> +m h d m w user test -e /run/systemd/system || test -e /usr/bin/<var>pkg</var> && /usr/bin/<var>pkg</var>
>
> Here is a more elaborate draft:
>
> https://github.com/ajtowns/debian-init-policy/pull/6/files
I'd really, *really* like to avoid having packages ship cron jobs that
wake up and run, only to immediately find that they have nothing to do
and stop. In addition to waking up the system unnecessarily to do
processing, this also results in log entries for that cron job,
producing a lot of unnecessary noise.
Debian's cron already has a large number of changes. I wonder if there's
any reasonable way that we could instead modify cron to accept some kind
of "mode" argument, and then condition entries or directories on "mode".
For instance, perhaps cron could take a command-line argument that
specified an additional directory to treat like cron.d, and
/etc/init.d/cron could specify an additional directory like
/etc/cron.sysv.d that /lib/systemd/system/cron.service did not. That
would make cron completely ignore those entries, never waking up for
them at all.
systemd has a detailed mechanism to make .service files supercede
corresponding init scripts. I'd love to have a similar mechanism to have
.timer files supercede corresponding cron.d scripts. Does the above
sound plausible as such a mechanism? Or could we do something else with
similar effect?
Reply to: