Adds an error assertion and replaces a deferred restore with
testutil.Backup (follow-up of #12859).
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
* timeutil: fix tests to run in non-UTC timezones
TestParseSchedule() has always failed for me - unless I set TZ=UTC before
running go test, since one of the tested time intervals encompasses a daylight
savings time transition here in my local timezone and so the result is different
in this case. Consequently, since this test always fails, building the snapd deb
or snap also fails for me locally. Fix this by forcing golang to use the UTC
timezone when running these tests, regardless of how they were invoked.
Signed-off-by: Alex Murray <alex.murray@canonical.com>
Co-authored-by: Miguel Pires <miguel.pires@canonical.com>
Go 1.19 includes some changes to gofmt which intend to make lists and
heading clearer when rendered (https://go.dev/doc/go1.19). This commit
is the result of running the new gofmt and manually fixing some of it.
This was necessary because the new gofmt assumed lines beginning w/ tabs
to start lists or examples. While this is often true in our codebase,
we occasionally also use tabs to indent the lines after a TODO or FIXME
prefix or in yaml (e.g., excerpts of a snap.yaml). This meant that a lot of the
reformatted comments were broken and had to be fixed manually.
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
Display information the hold placed by the user and the longest hold
placed by a gating snap, in the output of 'snap info'. The times are
displayed in an imprecise but user-friendly way.
Signed-off-by: Miguel Pires <miguel.pires@canonical.com>
This commit replaces the use of "sanity" with more inclusive
naming.
When `sanity` is used in a more general sense either `validity`
or `quick` is used.
* many: wait for up to 10min for NTP syncronization before autorefresh
We got bugreports that on systems without a proper clock the
auto-refresh code gets confused and reports strange refresh times.
It looks like this is triggered by snapd starting up and while in
the middle of the startup the NTP sync happens and that confuses
the autorefresh code that tries to calculate the next refresh window
because the clock is jumping.
To avoid this happening this commit adds code that waits for up
to 10min for the NTP syncronization to happen. This does not
fully eliminate the bug (that we still don't fully understand)
but it should fix it for most systems that have some sort of
network connection.
* {device,snap}state: rework ntp sync detection
* devicestate: rename/move ntpSyncedOrWaitedLongerThan
* timeutil: add missing dbus based tests
* devicestate: add tests around CanAutoRefresh and ntpSyncedOrWaitedLongerThan
* devicestate: clarify comments around TestNTPSyncedOrWaitedLongerThan
* devicestate: use time.Minute (thanks to Alberto)
* devicestate: use time.Nanosecond explicitely (thanks to Alberto)
* devicestate,timeutil: add/use timeutil.NoTimedate1Error
* timeutil: adjust test for new behavior
* devicestate: use errors.As and make test more realistic by using NoTimedate1Error.Err
* timeutil: remove unused code (thanks to Maciej)
* devicestate: ensure m.ntpSynchronized is cached and this is tested
* timeutil: fix misleading comment
* timeutil: fix typo (thank to Ian)
* devicestate: rename ntpSynchronized->ntpSyncedOrTimedOut to better reflect what it's about
As agreed, in order to resolve the ambiguity, each schedule is anchored at
either start (eg. mon1-fri), or at the end (mon-fri1). The anchor defines the
fixed time-point of the schedule, where the other end defines the span around
that point. Previously accepted schedules are not silently degraded to be
anchored at the starting point.
Having resolved the ambiguity, a week span including the last day of the month
can now be accepted and handled correctly, thus mon5-fri or mon-fri5 are valid schedules.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
The nth weekday is confusing on it's own. Adding week spans, the end result is
fuzzy at best.
Consider the following calendar:
August 2018
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
26 27 28 29 30 31
The schedule `mon1-tue1` matches 06.08 and 07.08, both days being he first
occurrence within the month.
However, extending the schedule to `mon1-fri1`, this should match: 01.08-03.08
and 06.08-07.08 (5 days total), so that the weekdays are inside the week span
defined in the schedule. If we let go of this property, and just match anything
between 03.08 and 06.08, the update could happen over the weekend, which is
clearly not intended.
Similarly, a schedule `mon2-fri2`, matches dates: 13.08-14.08 and 08.08-10.08 (5
days total).
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
Given a schedule with first weekday of the month (eg. wed1 - first Wednesday),
if a matching weekday happens on the first day of the month, it will be skipped
and instead the schedule will fall on the next same weekday of the month.
Consider the calendar:
August 2018
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
26 27 28 29 30 31
In case the schedule is on wed1, we are expecting the next window on 2018.08.01,
but instead the next window is scheduled for 2018.08.08.
The patch fixes buggy nth-weekday-of-the-month calculation for this edge case.
Signed-off-by: Maciej Borzecki <maciej.zenon.borzecki@canonical.com>
