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

David Strauss david at davidstrauss.net
Wed Feb 6 00:37:51 PST 2013

And, to bring this thread full-circle:


That will run on the last day of each month.

On Wed, Feb 6, 2013 at 12:34 AM, David Strauss <david at davidstrauss.net> wrote:
> Oh, one other current limitation is that it doesn't let you specify a
> time zone since the code just uses the current time (effectively in
> UTC) for DTSTART. We could support actual time zones if necessary by
> having an additional field like TimeZone= that gets passed into the
> "next event" calculation.
> I don't think this is a blocker.
> On Wed, Feb 6, 2013 at 12:27 AM, David Strauss <david at davidstrauss.net> wrote:
>> 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:
>> [Timer]
>> Recurrence=FREQ=minutely;BYWEEKNO=3;BYHOUR=9,11,13,15;BYSETPOS=-1
>> [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]
> --
> David Strauss
>    | david at davidstrauss.net
>    | +1 512 577 5827 [mobile]

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

More information about the systemd-devel mailing list