CalCalist/systemd/calcalist.timer

[Unit]
Description=Synchronise calendars with calcalist every 15 minutes

[Timer]
OnBootSec=2m
OnUnitActiveSec=15m
Persistent=true

# Spreads requests instead of every installation calling Google on the quarter
# hour. Google's Calendar API quota is per project and enforced per minute, and
# its own guidance is to randomise timing rather than to burst.
RandomizedDelaySec=120

[Install]
WantedBy=timers.target
Finish M2: run lock, systemd units, discover; drop the web UI Designing the configuration UI in full made the case against building it. Its audience would be people who find TOML hard, but with bring-your-own OAuth client settled, every user must first create a Google Cloud project, configure a consent screen and put a secret in a keyring — a far higher bar than editing thirty lines of config. Anyone who clears it can edit the file; anyone who cannot never reaches the file. Against that stood three dependencies, five modules, an auth.rs refactor and a security surface guarding something that reads the config and touches the keyring. `doctor` and `status` had already absorbed most of what it was for. The reasoning is recorded in TODO.md and SPECS.md rather than left as an apparent oversight. The run lock is not a UI feature and closes a gap that already existed: nothing stopped a timer firing into a hand-run cycle, and two cycles interleaving writes over the same vdirs is what the design otherwise avoids. flock is used rather than a pid file because the kernel releases it however the process ends, so a crash cannot leave a lock to clear by hand — which also means a lock we failed to take is held by a live process, so the pid in it is worth reporting. The one idea worth keeping from the UI design was collection discovery, which needed no web layer. `calcalist discover` prints a ready-to-paste endpoint block per calendar a server offers, removing the most error-prone field in the config. pimsync's discovery output is undocumented, so the format was established against a real server first. Two things it teaches: everything arrives on stdout including failures, and a pair has two storages, so pimsync reports the scratch vdir's contents too — parsing anchors on the heading naming the server, or a probe directory's leftovers would be offered as the user's calendars. Verified against Posteo as well as Radicale: all four calendars found, the first matching the URL already configured. Also fixes a real defect in the test harness rather than its symptom. Ports were chosen by binding one and letting go, so two tests could pick the same number — and the loser's readiness check then succeeded against the winner's server, silently sharing it. Startup now confirms the child we spawned is the one alive, retries on another port if not, and waits for a real HTTP response rather than an open socket. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> 2026-09-10 16:17:34 +03:00			`[Unit]`
			`Description=Synchronise calendars with calcalist every 15 minutes`

			`[Timer]`
			`OnBootSec=2m`
			`OnUnitActiveSec=15m`
			`Persistent=true`

			`# Spreads requests instead of every installation calling Google on the quarter`
			`# hour. Google's Calendar API quota is per project and enforced per minute, and`
			`# its own guidance is to randomise timing rather than to burst.`
			`RandomizedDelaySec=120`

			`[Install]`
			`WantedBy=timers.target`