You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The first speedtest picks its server right, and containers stop eating flags
The first speedtest after Start monitoring used to choose its server
before the connection had been looked at. Auto-select centres on a city
race whose candidates come from the connection info - the exit router's
city and the ISP's - but on a fresh install those lookups were still
gated when the ten-second countdown ended, so the race was skipped and
the Ookla API's guess at your location picked the server instead. Every
later run raced real cities and could land somewhere else entirely,
which made the first sample - the one that seeds the believed capacity
of your line - a measurement against a server nothing afterwards uses.
Now the connection lookups start the moment you press Start monitoring,
and the first test waits for them - up to twenty extra seconds, only if
it has to, and not at all when a server is pinned, a city is searched, a
working iperf3 engine is configured, or connection info is off. In
practice the lookup lands inside the existing ten-second countdown and
the first test starts exactly when it used to, now racing the same
cities every later test races.
The edges hold, each pinned by a deterministic test. Settings changes
can no longer slip between a check and the sleep that was supposed to
notice them - both loops subscribe before they read. Consent arriving
inside the daemon's three-second settle window takes the full first-run
path instead of running instantly. An install that starts on its own
after the 48-hour quiet period gets the same treatment (that path flips
no settings, so it gets its own poke). A test that finishes anywhere in
the first-run window - even in the instructions between the final check
and the start of the test - counts as the first test and schedules the
next one an interval after itself, never doubling up. And reboots of an
already-configured install still test within seconds, never waiting on
lookups.
Also in this release: setting PINGULARITY_OPTS in a container now tells
you it does nothing. The variable is a native Linux convention - the
systemd units expand it into command-line flags - and the container
images ignore it, which our first filed issue (#16) found the hard way.
A container that boots with it set now says so plainly, as the first
line of docker logs and again in the About tab - naming the variable,
never its value, which can carry secrets. Container flags go after the
image name (compose: under command:), and the README, the
/etc/default/pingularity file itself, and the security model doc now
say so. The Docker test workflow proves the whole chain on both images,
warning included.
Co-Authored-By: Claude <noreply@anthropic.com>
0 commit comments