Bug 1074951

I think that AccuracySec= already makes this possible.

OnCalendar=5:00
AccuracySec=1h

AccuracySec= is missing in the man pages for systemd 208 ( F20 )  and I dont think it crosses over days as in you cannot specify time period between days like weekends ( common time window for batch jobs to be run on servers )

Not usage friendly as in 

OnCalendar=5:00
AccuracySec=1h

Reads to me run at 6:00 even thou it might be randomized within a whole hour afterwards and it seems to be bound to a switch in systemd-system.conf ( ( TimerSlackNSec= ) which is one thing I dont think we want. 

Basically you dont want to add a master switch that can easily disrupt heavily loaded batch server with schedule jobs in the hundreds and thousands.

Those are new settings, so they are not present in stable Fedora.

TimerSlack is a different order of magnitude: it has a default value of 50us and probably should not be set to something higher than a few ms. OTOH, AccuracySec should work fine, even with periods of more than one day. All in all, I don't see too much problem with OnCalendar= + AccuracySec=. Note that this should work for all time specifications (OnCalendard=, OnBoot=...), and work fine with timer specifications which contain a dash.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #3)
> Those are new settings, so they are not present in stable Fedora.
> 
> TimerSlack is a different order of magnitude: it has a default value of 50us
> and probably should not be set to something higher than a few ms. OTOH,
> AccuracySec should work fine, even with periods of more than one day. All in
> all, I don't see too much problem with OnCalendar= + AccuracySec=. Note that
> this should work for all time specifications (OnCalendard=, OnBoot=...), and
> work fine with timer specifications which contain a dash.

I'm not so sure using AccuracySec solves this problem that batch administrator are faced with from a usability perspective as in

01 1 * * * 
02 1 * * *
03 1 * * * 
04 1 * * *
05 1 * * * 
06 1 * * *
07 1 * * * 
08 1 * * *
etc... 

Which could be solved by defining randomly run schedule within a given time frame

And if "AccuracySec" can solve this it is in no way descriptive name for that purpose

(In reply to Jóhann B. Guðmundsson from comment #4)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #3)
> > Those are new settings, so they are not present in stable Fedora.
> > 
> > TimerSlack is a different order of magnitude: it has a default value of 50us
> > and probably should not be set to something higher than a few ms. OTOH,
> > AccuracySec should work fine, even with periods of more than one day. All in
> > all, I don't see too much problem with OnCalendar= + AccuracySec=. Note that
> > this should work for all time specifications (OnCalendard=, OnBoot=...), and
> > work fine with timer specifications which contain a dash.
> 
> I'm not so sure using AccuracySec solves this problem that batch
> administrator are faced with from a usability perspective as in
> 
> 01 1 * * * 
> 02 1 * * *
> 03 1 * * * 
> 04 1 * * *
> 05 1 * * * 
> 06 1 * * *
> 07 1 * * * 
> 08 1 * * *
> etc... 
> 
> Which could be solved by defining randomly run schedule within a given time
> frame
If I understand your requirements correctly, this is what AccuracySec does.

> And if "AccuracySec" can solve this it is in no way descriptive name for
> that purpose
We should probably add some pointer in the On*= section to this setting.

AccuracySec= should cover this, starting with 209+. However, it will only really place the wakeup within 1min of range at max. If you set larger values it won't care... we can certainly change that though.

And we could add DefaultAccuracySec= to system.conf I figure...

(In reply to Lennart Poettering from comment #6)
> AccuracySec= should cover this, starting with 209+. However, it will only
> really place the wakeup within 1min of range at max. If you set larger
> values it won't care... we can certainly change that though.

I was wondering about that as in how well definable this actually was since the randomness needs to take place on a second level so when users define 

OnCalendar=5:00
AccuracySec=1m

It would run on a random second sometime in a 60s second range after 05:00 in the morning 

Or for an hour

OnCalendar=5:00
AccuracySec=1h

It would run on a random second sometime in a 3600 second range after 05:00 in the morning

Or for a full day

OnCalendar=5:00
AccuracySec=1d

It would run on a random second sometime in a 86400 second range after 05:00 in the morning 

Or for a two full days ( like a weekend )

OnCalendar=5:00
AccuracySec=2d

It would run on a random second sometime in a 172800 second range after 05:00 in the morning 

Etc.

> And we could add DefaultAccuracySec= to system.conf I figure...

I dont see the benefits of having such switch but maybe I'm missing something.

This got implemented as RandomizedDelay:
http://www.freedesktop.org/software/systemd/man/systemd.timer.html#RandomSec=

(In reply to Zbigniew Jędrzejewski-Szmek from comment #8)
> This got implemented as RandomizedDelay:
> http://www.freedesktop.org/software/systemd/man/systemd.timer.html#RandomSec=

Would it be possible to provide this feature in Fedora 23?

Either upgradeing to a higher systemd release, or backporting this feature to systemd 222 if you don't want to upgrade to a higher systemd release on Fedora 23?


I have tried to use AccuracySec to randomize the start time, as suggested in earlier comments, but it didn't work as expected. The timer has started the service within the first minute.

I need this feature to restrict dnf-automatic activation to the night (01:00h - 06:00h), because dnf update requests many disk ios and slow down interactive usage on the graphical console nearly to unuseability. But hundred of machines should not start dnf upgrade at the same time, they may get network connection timeouts.

(In reply to Edgar Hoch from comment #9)
> (In reply to Zbigniew Jędrzejewski-Szmek from comment #8)
> > This got implemented as RandomizedDelay:
> > http://www.freedesktop.org/software/systemd/man/systemd.timer.html#RandomSec=
> 
> Would it be possible to provide this feature in Fedora 23?

Yes, the patch is simple enough. Please, file a request for Fedora 23 and put this bugzilla in the "See Also" section, thank you.