• Bug#770440: debian-policy: policy should mention systemd timers

    From Josh Triplett@21:1/5 to alexandre.detiste@gmail.com on Sun Oct 22 22:40:02 2017
    XPost: linux.debian.bugs.dist

    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)