Refresh scheduling on specific days of the month

That was specifically addressed in the proposal, hopefully in a clear way:

As for the rest of your proposal, I think the main thing you’re trying to get out of it support for addressing years and months as well, in addition to organizing around weeks inside the month. The proposed syntax is extensible to that, but I’d prefer to not start from it at least, and learn a bit about the use cases once we have the basic features working.

There are multiple reasons for that. The first one is that I have a feeling people don’t really schedule low-level timers so specifically in practice. A production service that has a timer for a service on a single machine to run once over the whole year is an extremely optimistic design. Another reason that backs on the top of the former one is clarity… the less syntax we have, the easier it is to read and to write it.

As for your last point of using spaces and not .. to join the periods, it was addressed in the goals section: it’s much nicer to have a string that people don’t need to remember to quote upfront when they are writing it out, and it also feels like a more clear statement that the timer is composed by the whole. It’s a single timer, not two timers.

One thing I like about your proposal, by the way, is the idea of using an explicit “day” string instead of “-”. It feels more readable.

Read that twice and still found it a bit confusing, an example maybe, just to be sure that I got it right:

    November 2017   
Su Mo Tu We Th Fr  Sa
          1  2  3   4 
 5  6  7  8  9 10  11 
12 13 14 15 16 17  18 
19 20 21 22 23 24 |25|  <-- Nov 25 is both sa4 and sa5?
26 27 28 29 30       

Allowing to specify ‘last Friday’ actually makes sense, I’m just not sure about fri5.

Syntax wise, I think both proposals are close. Joining periods with .. is fine with me. Personally, I prefer using whitespace (implementation-wise we could probably support both) or having multiple --timer ... arguments in the command line.

I’ll give it another look in the morning, a rested mind may come up with more ideas :slight_smile:

One more thing, somewhat unrelated to the syntax, but more to the execution. Is it possible to inhibit the timer from running? A use case that I’ve seen come up before is that the host/device is performing some critical task and while it’s being done no other functions that may have a negative impact (performance wise or just generally operation wise) are allowed. Should I bring that up in another thread perhaps?

Yeah, that’s it.

Definitely a special case. The rationale is this: there’s absolutely no point in having something that schedules an event for a weekday that will only recur rarely and in non-interesting situations. There is value however in the notion of the last one.

So, if we support a fri1, 2, 3, and 4 meaning those respective weeks, which sounds like a good idea, then supporting 5 as meaning the last one is the only reasonable option for that. The other option would be to not have it at all, or to have a different syntax altogether. Could not think of something better myself, yet at least.

Supporting both is the worst option, because then everybody has to remember that both mean the same thing, and teams will need conversations about something as silly as the preferred timer syntax. Lacking any better ideas or real issues, let’s please stick to the proposal.

We already had some discussions about this, including here in the forum, and yes we’ll want to implement support for snaps to say “not now, please”. But no need to discuss this now… we know we want it, and we know how we’ll do it (hook plus snapctl command). We just won’t do it right now as we have higher priority items in front of it.

The first piece landed in a PR today https://github.com/snapcore/snapd/pull/4269 It’s a parser for the spec that @niemeyer described. See the PR comment for details. It is mostly close to the proposal.

Short list of what’s possible:

  • mon-fri,10:00-15:00 - Mondays to Fridays, between 10am and 3pm
  • mon-fri,10:00-15:00 - same as above, but the event time is randomized within the window
  • fri-mon,10:00-15:00 - Fridays to Mondays, between 10am and 3pm
  • weekend,10:00 - 10am on weekends (weekend is an alias for sat-sun)
  • 23:00-01:00 - every day between 11pm and 1am the next day
  • day/4 - 4 times a day, every day (instead of -/4, day is an alias for 0:00-24:00)
  • mon5,23:00-01:00 - last Monday of the month, from 11pm to 1am the next day
  • mon1-mon2,0:00-6:00 - from the first Monday of the month to the 2nd Monday, from midnight to 6am
  • 23:00-24:00 - from 11pm to midnight (24:00 is the same as 0:00 but it occurs later in the day)
  • mon,3:00-6:00..fri,22:00-0:00, Mondays from 3am to 6am, Fridays from 10pm to midnight
1 Like

Long time lurker here, getting out to bikeshed (sorry!)… but I can’t resist from saying that “..” looks really weird to me.
Probably because I somehow expect it to be a range operator (as in Perl, Ruby etc.), while here it’s not.

Also “,” looks too overloaded (means both “AND” and “AT”), since it separates:

  1. day lists (mon,fri => AND)
  2. time lists (10:00,15:00 => AND)
  3. day from time (mon,10:00 => AT)
  4. day lists from time lists (mon,fri,10:00,15:00 => AND+AT+AND)

The latter I find confusing.

I think both problems could be fixed by using:

  • “@” in place of “,” to separate days from times (case 3 and 4 above)
  • “,” in place of “..

This way the example in PR #4313:

    mon,10:00..fri,15:00 (Monday at 10:00, Friday at 15:00)
    mon,fri,10:00,15:00 (Monday at 10:00 and 15:00, Friday at 10:00 and 15:00)
    mon-wed,fri,9:00-11:00/2 (Monday to Wednesday and on Friday, twice between 9:00 and 11:00)
    mon,9:00~11:00..wed,22:00~23:00 (Monday, sometime between 9:00 and 11:00, and on Wednesday, sometime between 22:00 and 23:00)
    mon,wed  (Monday and on Wednesday)
    mon..wed (same as above)

would become:

    mon@10:00,fri@15:00
    mon,fri@10:00,15:00
    mon-wed,fri@9:00-11:00/2
    mon@9:00~11:00,wed@22:00~23:00
    mon,wed
    mon,wed

Re-reading the thread, this looks like the original proposal by @niemeyer.
I can’t see how the new syntax being implemented is better, but maybe I’m missing something obvious…

2 Likes

We are close to landing the parser bit of the code with 4313. After some discussion we’ve addressed the range feel of .. and decided to go with ,, instead (unfortunately there’s not that many shell-friendly characters left to choose from). This makes the examples look like this:

mon,10:00,,fri,15:00 (Monday at 10:00, Friday at 15:00)
mon,fri,10:00,15:00 (Monday at 10:00 and 15:00, Friday at 10:00 and 15:00)
mon-wed,fri,9:00-11:00/2 (Monday to Wednesday and on Friday, twice between
                          9:00 and 11:00)
mon,9:00~11:00,,wed,22:00~23:00 (Monday, sometime between 9:00 and 11:00, and
                                 on Wednesday, sometime between 22:00 and 23:00)
mon,wed  (Monday and on Wednesday)
mon,,wed (same as above)

Thank you @mborzecki. While I really appreciate you reconsidered the .. token, I still think my proposal above sounds far more natural (@ is shell-safe after all, isn’t it?).
But maybe it’s just me and this is subjective ground, so I won’t push further.

The parser has landed. I already have the code replacing refresh.schedule with refresh.timer but after some thought I need additional clarification from @niemeyer.

# use format compatible with the old parser
$ sudo snap set core refresh.timer=12:00-13:10 
$ sudo snap set core refresh.schedule=""
$ snap refresh --time
schedule: 12:00-13:10 
$ snap refresh --timer
timer: 12:00-13:10 

# incompatible with old parser
$ sudo snap set core refresh.timer=mon,12:00-13:10 
$ sudo snap set core refresh.schedule=""
$ snap refresh --time
schedule: mon,12:00-13:00   # cut-n-paste to refresh.schedule will fail
$ snap refresh --timer
timer: mon,12:00-13:10 

And there’a perculiar case of refresh.schedule=managed. For now I have assumed that refresh.schedule == managed takes priority over refresh.timer.

Edit: proposed changes are in this PR: https://github.com/snapcore/snapd/pull/4476

All of this has landed now.

1 Like

One thing to note is that we currently have a systemd timer unit that does a ‘snap refresh’ once a week. This was placed there when we moved to using the internal timer, in case things got stuck; a system administrator that wants to have refreshes happen on a longer cadence than weekly needs to modify (or disable) this file. A systemctl disable snapd.refresh.timer would accomplish the latter.


There is still value in having this systemd timer as a a fallback, in case a bug betwen snapd and the system clock result in snapd’s refresh timer not working, but snapd needs some changes to be more aware of this.

This’ll also let us stop it looking weird in the changes log.

As we discussed in the standup today, that feels somewhat awkward, and also a bit unexpected in the sense that I remember we disabled this in the past, but it came back in a different way.

Can we just kill that timer for good and ensure the real mechanism works reliably and always?

cc @mborzecki

1 Like

I have made the changes that drop snapd.refresh.timer. I still need to finish reviewing how we use the timer so that we do not run into issues with monotonic timers. If I understand the problem correctly, we should be ok.

One scenario that we probably didn’t think of is when someone is using socket activation of snapd and the snapd.socket is the only service that is activated on boot. Unless someone performs an action that activates snapd, it will remain inactive and none of the refresh times will be hit.

As recommended by @Ads20000 (topic to be moved from original thread)

Sorry for a second reply but I didn’t have time until recently to review proffered information.

“You’ll want sudo snap set core refresh.timer= as documented here.” (here is a hot link)

memyself@debianserver:~$ sudo snap get core refresh.timer
[sudo] password for memyself:
error: snap “core” has no “refresh” configuration option
memyself@debianserver:~$ snap get refresh.timer
error: access denied (try with sudo)
memyself@debianserver:~$ sudo snap get refresh.timer
error: snap “refresh.timer” has no configuration

Last command - - - I am trying to use commands as set out in the referred to document - - please note the result.

memyself@debianserver:~$ snap refresh --time
timer: 00:00~24:00/4
last: today at 08:22 CDT
next: today at 14:34 CDT
You have new mail in /var/mail/memyself
memyself@debianserver:~$ snap set core refresh.timer=fri5,23:00-01.00
error: access denied (try with sudo)
memyself@debianserver:~$ sudo snap set core refresh.timer=fri5,23:00-01.00
error: cannot perform the following tasks:

Run configure hook of “core” snap (run hook “configure”: cannot parse “23:00-01.00”: not a valid time)
memyself@debianserver:~$ snap configure
error: unknown command “configure”, see ‘snap help’

(Didn’t copy the complete ‘help’ list but here is the attempt to configure the timer given the ‘only’ option given for configuration termed ‘set’)

memyself@debianserver:~$ sudo snap set refresh.timer
error: the required argument (at least 1 argument) was not provided

so I try again using the syntax as delineated in one of the examples in the directed to document:

memyself@debianserver:~$ sudo snap set refresh.timer=fri5,23:00-01:00
[sudo] password for memyself:
error: the required argument (at least 1 argument) was not provided

So - - - to me - - - this looks like something that I’m locked into with no possibility for my input

please advise as to the actual process to affect the requested change.
Sorry for a second reply but I didn’t have time until recently to review proffered information.

“You’ll want sudo snap set core refresh.timer= as documented here.” (here is a hot link)

memyself@debianserver:~$ sudo snap get core refresh.timer
[sudo] password for memyself:
error: snap “core” has no “refresh” configuration option
memyself@debianserver:~$ snap get refresh.timer
error: access denied (try with sudo)
memyself@debianserver:~$ sudo snap get refresh.timer
error: snap “refresh.timer” has no configuration

Last command - - - I am trying to use commands as set out in the referred to document - - please note the result.

memyself@debianserver:~$ snap refresh --time
timer: 00:00~24:00/4
last: today at 08:22 CDT
next: today at 14:34 CDT
You have new mail in /var/mail/memyself
memyself@debianserver:~$ snap set core refresh.timer=fri5,23:00-01.00
error: access denied (try with sudo)
memyself@debianserver:~$ sudo snap set core refresh.timer=fri5,23:00-01.00
error: cannot perform the following tasks:

Run configure hook of “core” snap (run hook “configure”: cannot parse “23:00-01.00”: not a valid time)
memyself@debianserver:~$ snap configure
error: unknown command “configure”, see ‘snap help’

(Didn’t copy the complete ‘help’ list but here is the attempt to configure the timer given the ‘only’ option given for configuration termed ‘set’)

memyself@debianserver:~$ sudo snap set refresh.timer
error: the required argument (at least 1 argument) was not provided

so I try again using the syntax as delineated in one of the examples in the directed to document:

memyself@debianserver:~$ sudo snap set refresh.timer=fri5,23:00-01:00
[sudo] password for memyself:
error: the required argument (at least 1 argument) was not provided

So - - - to me - - - this looks like something that I’m locked into with no possibility for my input

please advise as to the actual process to affect the requested change.

He (@Ads20000)
requested the following information.

$ snap version
snap 2.32~pre4+git612.2003af8~ubuntu16.04.1
snapd 2.32~pre4+git612.2003af8~ubuntu16.04.1
series 16
debian 9
kernel 4.9.0-6-amd64

Is there a bug that is affecting my ability to set the refresh timing?

1 Like

This string broken. Note the “.” instead of “:” on the second time. If you fix that, it should work (it does for me).

@mborzecki Related question: why is “next” showing an incorrect time for this schedule after it is accepted? Perhaps it’s waiting until the next ensure? If so, we should schedule an ensure (EnsureSoon) when we accept a new value.

OK - - - entered as requested. Checked for the result - - - it does not look like the command ‘worked’.

$ sudo snap set core refresh.timer=fri5,23:00-01:00
[sudo] password for memyself:
memyself@debianserver:~$ snap refresh --time
timer: fri5,23:00-01:00
last: 2018-03-25T09:19:00-05:00
next: 2018-03-25T14:27:00-05:00

The last line suggest thats the requested change (done with set ‘core refresh.timer’) wasn’t incorporated.

Please advise on how to achieve the requested change.

https://snapdocs.labix.org/configuration-options/87
Above page is what I’m trying to use as a guide (its not very easy to follow!!).

If it doesn’t error, it did work. About the output of the --time option, please see the point I made in my previous message.

Fascinating - - - background controls give 2 different answers purely based on time. (Re-did the last command and now the resultant is different but giving the response programmed in.)

IMO the dev team’s iron fisted control on updates is producing a seriously convoluted product.

@dabeegmon There’s a delay in the logic that reschedules the next window of updates. That’s a bug.

It’s pretty unfortunate to receive such backhanded comments when we go over the trouble we do to be helpful. But you’re welcome, @dabeegmon.

1 Like