Author SHA1 Message Date
sneak d9497319c3 Bring TODO.md Status and Next Step to the run in progress (closes #251)
check / check (push) Successful in 6m29s
Status and Next Step described the 24-hour run of 9bd0e91, whose outcome
was posted on issue 226 on 3 November. They now describe the run of
e58c663 on issue 232: at least 24 hours, then on until the feed stalls or
reconnects, up to 72 hours, and what its outcome reports. Two Completed
Steps entries of 10 November are rewritten: the ProtonVPN entry ran past
30 words, and the busy-host test entry referred to waits it had not named.
The PTR entry defines TTL. An entry for this read is added.

Model: fable-5-1
2026-11-10 16:32:28 +00:00
sneak 7e8aae1875 Rewrite the README sentences that fail the prose rules or disagree with the code
A fresh read of README.md whole against the rules of issue 157, with every
statement except measured figures and what outside services do checked
against the code on next. Four sentences fail the prose rules, all in
sections added since 742e759: the origin change definition, the first uses
of TTL and SOA record, and the geojs request. Five disagree with the code:
the geojs request carries only the addresses the cache does not hold; after
a write fails on SQLite's hard heap limit, the prefix handler also writes
its origin changes again, and the PTR and geolocation caches write their
answers again; the test rerun on failure drops -cover; and latitude and
longitude are in degrees, which their names do not say.

Model: fable-5-1
2026-11-10 16:32:04 +00:00
clawbot 6de44ac054 Create the image's app user without the system-user flag (closes #248)
check / check (push) Successful in 1m8s
`useradd -r` asks for a system user and UID 1000 is above the system range, so the image build warned. Dropping `-r` ends the warning; the user keeps UID 1000, so the owner of the data directory does not change.

Model: opus-5-5
2026-11-10 16:23:20 +01:00
3 changed files with 42 additions and 33 deletions

No files matched your search

+1 -1
View File
@@ -105,7 +105,7 @@ RUN apt-get update && apt-get install -y --no-install-recommends \
ARG CACHEBUST
# Create non-root user
RUN useradd -r -u 1000 -m routewatch
RUN useradd -u 1000 -m routewatch
RUN mkdir -p /var/lib/berlin.sneak.app.routewatch && chown routewatch:routewatch /var/lib/berlin.sneak.app.routewatch
+13 -9
View File
@@ -143,8 +143,9 @@ and origin AS can have two kept routes, one or none.
AS path, a next hop and a time. The next hop is the router the peer sends the
prefix's traffic to. RouteWatch records the peer itself as the next hop. The
page also lists the prefix's origin changes, newest first. An origin change is
recorded when an AS gains its first peer for the prefix, or loses its last.
The page shows at most the newest 5,000. Each row shows:
recorded when the first peer starts to carry the prefix with an origin AS, or
when the last peer stops. The page shows at most the newest 5,000. Each row
shows:
- the time
- announced or withdrawn
- the origin AS
@@ -196,8 +197,9 @@ also carries an `@meta` object:
- `api_version`: `1`
- `execution_time_ms`: the number of milliseconds the request took
Every value with a unit is a number, and the unit ends the field name. Examples
are `_ms`, `_seconds`, `_bytes`, `_per_sec` and `_per_min`.
Every value with a unit is a number. The unit ends the field name, as in `_ms`,
`_seconds`, `_bytes`, `_per_sec` and `_per_min`. `latitude` and `longitude` are
in degrees, and their names do not say so.
The paths:
@@ -521,7 +523,7 @@ An IP lookup finds where each address is, on a best-effort basis. It uses two
sources:
- [geojs](https://www.geojs.io/) is asked first. One request carries every
address of the lookup that the cache does not hold, and it has 1 second to
address of the lookup that the cache does not hold. geojs has 1 second to
answer.
- [DB-IP City Lite](https://db-ip.com/db/download/ip-to-city-lite) answers when
geojs has no answer for the address. It is a database file that RouteWatch
@@ -704,8 +706,10 @@ What happens at each limit:
allocating more.
- The SQLite hard heap limit: a database statement fails with an out-of-memory
error, which the handler logs. The prefix handler writes the routing table's
changes again in a later write. Everything else in the failed write is
dropped. The process keeps running.
changes and its origin changes again in a later write. Everything else in a
handler's failed write is dropped. The PTR cache and the geolocation part
write their answers to `cache.db` again in a later write. The process keeps
running.
- The handler queues: the handlers are the four parts that take the feed's
messages (see Design). The prefix handler's queue holds at most 100,000
messages, about 100 MiB. Each of the other three holds at most 20,000. When a
@@ -1072,8 +1076,8 @@ calls one of them. The scripts:
- `script/projectname`: print the project name, `routewatch`, which
`script/docker` uses as the image tag.
- `script/test`: build the `test` phase of the `Dockerfile` alone. It runs
`go test -short -count=1 -timeout 90s -race -cover ./...`, and reruns it with
`-v` on failure.
`go test -short -count=1 -timeout 90s -race -cover ./...`. On failure it runs
the tests again with `-v` and without `-cover`.
- `script/lint`: build the `lint` phase of the `Dockerfile` alone. It runs
`golangci-lint` v2.14.0 with `.golangci.yml`.
- `script/fmt`: format the Go code with `go fmt` and the markdown with
+28 -23
View File
@@ -22,18 +22,17 @@ formatting of the Go code and the markdown. Then it builds the image.
The image sets memory ceilings for a 5 GiB container (README "Memory"). README
"Running under upaas" says how to run it.
Since 2026-10-27, `next` has run on the live feed five times, from three hours
to five days. The runs found the handlers dropping updates for five causes, and
the WHOIS fetcher asking a registry that had refused it. Each is fixed on
`next`, and its Completed Steps entry below names its issue. A 21-hour run of
`742e759`, which has every fix but one, dropped no update except after the feed
stalled. That cause, https://git.eeqj.de/sneak/routewatch/issues/229, is fixed
on `next`.
Five runs of `next` on the live feed have ended since 2026-10-27, from three
hours to five days long. The runs found the handlers dropping updates for five
causes, and the WHOIS fetcher asking a registry that had refused it. Each is
fixed on `next`, and its Completed Steps entry below names its issue. A 21-hour
run of `742e759`, which has every fix but one, dropped no update except after
the feed stalled. That cause, https://git.eeqj.de/sneak/routewatch/issues/229,
is fixed on `next`.
A 24-hour run of `e58c663` on the live feed began at 09:19 UTC on 2026-11-10
(https://git.eeqj.de/sneak/routewatch/issues/232). It reads whether any handler
drops an update, the size of the `origin_changes` table on disk, and the
process's peak memory against 5 GiB. The seven IP lookup additions of
A run of `e58c663` on the live feed began at 09:19 UTC on 2026-11-10
(https://git.eeqj.de/sneak/routewatch/issues/232). It is to confirm that fix.
Next Step lists what its outcome reports. The seven IP lookup additions of
https://git.eeqj.de/sneak/routewatch/issues/203 landed after it began, so it
does not exercise them.
@@ -42,13 +41,15 @@ https://git.eeqj.de/sneak/routewatch/issues/86.
# Next Step
Post the outcome of the 24-hour run of `e58c663` on
https://git.eeqj.de/sneak/routewatch/issues/232. The run lasts 24 hours, or
until the feed has stalled or reconnected once, up to 72 hours. The outcome
says:
Post the outcome of the run of `e58c663` on
https://git.eeqj.de/sneak/routewatch/issues/232. The run lasts at least 24
hours. If the feed has not stalled or reconnected by then, the run goes on until
it does, up to 72 hours in all. The outcome says:
- whether any handler dropped an update, and the prefix queue's high-water mark
- the held-back count
- whether the feed stalled or reconnected
- whether any handler dropped an update, and the most messages the prefix
handler's queue held at once
- the most messages the prefix handler held back at once
- the size of the `origin_changes` table on disk
- the process's peak memory against 5 GiB
@@ -57,11 +58,14 @@ File an issue for each problem the run finds.
# Completed Steps
- 2026-11-10: `README.md` and this file are read whole against the rules of
https://git.eeqj.de/sneak/routewatch/issues/157, and every statement is
checked against the code on `next`. Four README sentences, on origin changes,
PTR lookups and geolocation, are rewritten. Status and Next Step describe the
live-feed run in progress (closes
https://git.eeqj.de/sneak/routewatch/issues/251).
https://git.eeqj.de/sneak/routewatch/issues/157, and every statement except
measured figures and what outside services do is checked against the code on
`next`. Four README sentences failed the prose rules. Five disagreed with the
code. Each is rewritten. Status and Next Step describe the live-feed run in
progress (closes https://git.eeqj.de/sneak/routewatch/issues/251).
- 2026-11-10: the image creates the `routewatch` user as a regular user with UID
1000, so the build no longer warns about the system UID range (closes
https://git.eeqj.de/sneak/routewatch/issues/248).
- 2026-11-10: each result of the IP lookup has `geo`, where the address is. It
comes from geojs, with DB-IP's City Lite database as the fallback. The geojs
answers stay in memory and in `cache.db` for 7 days (closes
@@ -74,7 +78,8 @@ File an issue for each problem the run finds.
servers, and `protonvpn_entry` holds the servers' IPv4 and IPv6 addresses
(closes https://git.eeqj.de/sneak/routewatch/issues/236).
- 2026-11-10: the IP lookup finds PTR names over DNS-over-HTTPS and caches them
for the record's TTL, in memory and in `cache.db` (closes
in memory and in `cache.db` for the record's TTL. A TTL is the time for which
a DNS record may be kept (closes
https://git.eeqj.de/sneak/routewatch/issues/238).
- 2026-11-10: the tests no longer fail when a busy host stalls for several
seconds. Most waits for something that should happen are now 15 seconds. Tests