Dear Maintainers,

I've seen that util-linux was the first package that started providing
a native systemd timer for fstrim, but this change got reverted.

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

Alexandre Detiste

Alexandre Detiste <alexandre.detiste@gmail.com> writes:

This proposal seems reasonable, but the above is a pull request against
some other document that wasn't ever merged with Policy (and is something
of a separate issue).

Could you formulate this as a patch against the debian-policy package?

Hi,

This is the most interresting mail I ever salavaged from my gmail spam folder.

There's now apt-daily.timer that is shipped with apt and got accepted
with much less complaints; I'll have a look a this one when I'll
refresh my wording.

Ok, will do.

Alexandre Detiste

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?