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

[David Strauss]

On Thu, Feb 7, 2013 at 8:11 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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.

I discussed this a bit with Kay, and I think we all agree that it's
not ideal to put this in PID 1. I'd prefer to do this sort of unit
interpretation/parsing outside of PID 1. All PID 1 really needs to be
managing is the icalrecurrencetype struct (an opaque, fixed-size set
of bytes) and the ability to send it off for calculation of the next
recurrence time. Unfortunately, there's no current provision for that.

Perhaps we could spin off unit (re)loading into a process that
communicates back to PID 1 with the parsed, validated data? We could
even move the dependency graph calculations out of PID 1 to open up
library use for (much needed) improved performance. It would also make
unit testing cleaner because it would produce a deterministic,
serialized structure based on the inputs.

> 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 ...

Parsing the rule is not nearly as complex as the calculation of
recurrence times. There's no simple way for us to support running,
say, a report on the first full week of the year.

> 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 do consider the COUNT part of the syntax a detail we can avoid,
either by ignoring it or throwing a parse error when we see it.

> 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.

The mapping problem is relatively easy because the current OnCalendar
spec is, I think, a proper subset of iCal's capability.

[1] http://doxygen.db48x.net/mozilla-full/html/dd/d72/structicalrecurrencetype.html
[2] http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/calendarspec.h

--
David Strauss
   | david at davidstrauss.net
   | +1 512 577 5827 [mobile]