[systemd-devel] Feature request: schedule jobs for last day of month

[Lennart Poettering]

On Tue, 05.02.13 11:54, David Strauss (david at davidstrauss.net) wrote:

> 
> Repeating myself, but I'll say it again: I strongly prefer a feature
> set that is a subset of iCal/xCal [1]. I'd like it to be possible in
> the future to expose existing and future runs via CalDAV over
> something like the gateway.
> 
> iCal already supports "last day of month schedules":
> 
> FREQ=MONTHLY;INTERVAL=1;BYMONTHDAY=-1
> 
> Maybe we should make it more systemd-ish in how we specify everything,
> but it's all there. Developers have given the administrative
> requirements of recurring events decades of thought and mostly arrived
> at iCal, and Apple, Google, and other calendar implementers have
> standardized on it. There are also FOSS libraries for computing
> recurrence times in the iCal format [2]. libical has friendly
> licensing, uses GNU Autotools, returns cleanly on memory allocation
> errors, is actively maintained (frequent commits), is broadly used in
> production services, includes pkg-config data for easy linking, and
> comes packaged in major distributions like Fedora.

We are very conservative in adding new deps to PID 1. PID 1 is an almost
kernel-like environment, if it goes down the entire system is
lost. Pulling in another library into this, that so far has not been
part of the usual Linux stack, for a relatively peripheral use is not
really something we are particularly keen on. And we cannot really make
this an optional dependenciy either, since that might have the result
that people can write timer files that parse on some systems but not on
others, and we really want to avoid that.

Ultimately, if we really would want such a complex recurrence logic in
there, then it would probably be easier to just reimplement it. It's not
that hard really, the syntax does not appear particularly complex to me,
looking at http://www.kanzaki.com/docs/ical/recur.html ...

That said, I am not even convinced we actually do want the complex
recurrence logic of ical here. Currently, the language implemented may
be used to declare repetitive events where the engine will always
calculate the next occurence right after a the job finished running the
last time, and then trigger the event on that. As next step, whe then
want to add anacron-like functionality where this logic learns
persistance, and thus the last execution time is saved to disk so that
we can take this into account after a reboot, too.

However, the ical recur stuff goes an important step further beyond the
current logic: COUNT= may be used to indicate the total amount of
executions, but that's something very different from what is implemented
now. The currently implemented scheme does not specify anything about
the number of times something is executed, it leaves that pretty much
open, it just declares that when -- after a job is completed -- the next
time should be scheduled. If a job however runs very long (so that it
overruns the next occurence), the current implemenation (and syntax)
will not retrigger immediate reexecution. Now, adopting the ical syntax
hence would also mean that to be fully in compliance with its logic we
would have to improve the engine to count previous executions and
possible persist that to disk.

Of course, one could claim that this is a tiny detail we could just
ignore, but I believe picking a good calendar language is mostly about
getting these details right.

I mean, it took us a long time to finally add calendar scheduling
support to systemd. The reason for that was not that this was inherently
a hard problem (it's not hard really, it took me a day or so to
implement in the end), but it was that we were so unsure about the
calendar expression language we should use for this. David, you had
proposed ical a while back already, and we looked into that in
detail. We however were a bit uncomfortable with the syntax, as we
figured the ISO date notation was not really that nice to type for
humans, and due to its heavy use of upper-case for the recurrence stuff,
abbreviations and other syntax pecularities it kinda felt a bit alien in
the rest of the systemd syntax. We looked into various other syntaxes we
found, and temporarily even considered just taking over the old
cron-syntax, because that was very simple at least. We also felt that
supporting redundant calendaring languages would be a big mistake, we
should stick to one, and make it a good one, rather than supporting
multiple ones with all each individual shortcomings.

The syntax we finally settled on is mostly inspired (but different in
some key areas) by Uwe Ohse's work on uschedule:

http://ohse.de/uwe/uschedule/uschedule.html

When I found that I was really happy, because these time specifications
where easy to write, easy to read, and still substantially more powerful
than cron. This language was particularly nice as normal timestamps were
naturally extended to recurring events. Timestamps hence mostly became a
subset of repetive event specifications, and what we output is very
close to what we pars.e And so we took that, adapted it a little and
used that in systemd.

Now, I can totally see the benefit of being able to map iCal events to
timer units. There's a strong usecase behind that, I can totally see
that. However, I wonder if it wouldn't be better to actually treat that
as that what it is, i.e. a "mapping" problem. So maybe the approach here
could be to figure out in detail what ical can express right now, that
systemd cannot right now, then maybe update systemd to do a little bit
more, and then document in the wiki how we propose the mapping to work
if clients want to do that, including example code. And all that while
documenting explicitly where the ical logic differs from the systemd
logic, like for example for the COUNT= part pointed above.

(I have now added this to the TODO list.)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.