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

David Strauss david at davidstrauss.net
Wed Feb 6 00:27:26 PST 2013

Here is a version that is tested and, with review, I think ready to
commit. This adds a unit test to exercise the "next event" logic,
to/from string wrappers, and validity checks.

This represents a near superset of existing scheduling. For example:

 * "FREQ=minutely" will execute every minute, starting 60 seconds from
when the unit started.
 * "FREQ=minutely;BYSECOND=0" will execute every minute on the minute,
starting the first time the clock shows 00 seconds.

Of course, any other iCal RECUR syntax [1] is supported. The only
notable exceptions are:

 * Having a fixed recurrence count won't have any effect because we
recalculate the start of the sequence every time systemd asks for the
next occurrence. You can, however, specify an end date/time.
 * For the same reason as the first exception, there's no ability to
have a recurring event start its sequence in the future.

So, if you want to have an event run every minute during the third
week of the year on odd hours between 9am and 5pm, except for the
second to last occurrence, go for it:


[1] http://www.kanzaki.com/docs/ical/recur.html

On Tue, Feb 5, 2013 at 9:03 PM, David Strauss <david at davidstrauss.net> wrote:
> I haven't tested this other than ensuring that it compiles with iCal
> support (default) and with --disable-ical.
> I opted for putting the modularity into which sources get compiled,
> like the gateway, which necessarily requires some #ifdefs in the timer
> code. I could also put the modularity into the recurrence code itself.
> I looked at adding test code similar to the calendar set, but it's
> mostly a parser tester. This parser library has its own test suite.
> There still may be some room to test wrapper function like the next
> time calculation.
> Also, no man page updates yet. I'd like to get the code in shape and
> reviewed first.
> On Tue, Feb 5, 2013 at 7:34 PM, Zbigniew Jędrzejewski-Szmek
> <zbyszek at in.waw.pl> wrote:
>> On Tue, Feb 05, 2013 at 06:48:23PM -0800, David Strauss wrote:
>>> On Tue, Feb 5, 2013 at 6:17 PM, Kay Sievers <kay at vrfy.org> wrote:
>>> > Many of the things in iCal we *really* don't want or need, like the
>>> > re-occurrence counters we would need to store and we likely don't want
>>> > that kind of state, the time zones which I think we should entirely
>>> > ignore for a system service, weird things like dependencies on the Mon
>>> > vs. Sun start of the week.
>>> Recurrence counts don't require any state. iCal just computes N
>>> recurrences since the start data and time. If they get missed, it's
>>> handled the same way as if cron has a job scheduled for Sundays and
>>> the computer is turned off that day. That said, I don't find this
>>> capability too useful.
>>> Time zones actually can be useful for scheduling heavy jobs around low
>>> utilization times. Work and utilization schedules follow DST changes.
>> Also: send summaries of mailing list statistics on very first of the month,
>> 12 am local time.
>> Or: start syncing Fedora repositories on Jan 15 1 PM EST.
>>> > It all sounds a bit like a "I do because I can" thing, because it
>>> > looks easy to plug in a library that says it does all that, but is
>>> > that really something needed and useful for a system service to
>>> > schedule?
>>> The first question is if we want to support business-style scheduling
>>> based on things like the "first Friday of the month" or "10 days
>>> before the end of the trimester." If so, iCal RECUR is the obvious
>>> path forward.
>>> It's not about being someone's personal calendar as much as
>>> recognizing the role service scheduling has in business.
>> Yeah, I think it is definitely at least worth investingating.
>> Zbyszek
> --
> David Strauss
>    | david at davidstrauss.net
>    | +1 512 577 5827 [mobile]

David Strauss
   | david at davidstrauss.net
   | +1 512 577 5827 [mobile]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ical.patch
Type: application/octet-stream
Size: 14965 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20130206/92929e2e/attachment.obj>

More information about the systemd-devel mailing list