thesabear/public
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update cron scheduler md file

Browse Source
This commit is contained in:
thesabear committed 2026-08-28 07:42:33 +03:00
1 parent 613d613535
commit 846e02e659
1 file changed
-8
Download Patch File Download Diff File Expand all files Collapse all files
docs/cron-scheduler.md
-8
View File
@@ -35,13 +35,5 @@ Populating 50 rows by hand across a dozen-plus different systems wasn't just dat
- **The heaviest job in the entire fleet isn't a backup.** Radarr's own `Refresh Movie` task runs ~1h15min daily — heavier than any single PVE backup job, and the heaviest scheduled task found anywhere in the *arr media suite. Radarr's own backup job, by contrast, finishes in about 41 seconds. - **The heaviest job in the entire fleet isn't a backup.** Radarr's own `Refresh Movie` task runs ~1h15min daily — heavier than any single PVE backup job, and the heaviest scheduled task found anywhere in the *arr media suite. Radarr's own backup job, by contrast, finishes in about 41 seconds.
- **A 404 that looked like an auth problem wasn't one.** Pulling Authentik's 18 internal task schedules initially 404'd against the endpoint documented for older versions (`/admin/system_tasks/`) — the real one had moved to `/api/v3/tasks/schedules/` in the installed version. A wrong assumption about *why* something failed costs more time than the actual fix would have. - **A 404 that looked like an auth problem wasn't one.** Pulling Authentik's 18 internal task schedules initially 404'd against the endpoint documented for older versions (`/admin/system_tasks/`) — the real one had moved to `/api/v3/tasks/schedules/` in the installed version. A wrong assumption about *why* something failed costs more time than the actual fix would have.
## Two real, unresolved gaps this system surfaced
> [!IMPORTANT]
> **A silently broken prune job.** PBS's own prune job targets a datastore name that doesn't actually exist on the backup server — only one real datastore name is in use elsewhere on the same server. Not a scheduling collision, an orphaned config that's been failing every run without anyone noticing. Two fixes are on the table, deliberately left unresolved rather than guessed at: drop the dead job and let Proxmox VE's own `keep-last` retention be the sole authority, or repoint it at the real datastore name and let PBS's own richer daily/weekly/monthly retention rules take over instead. Moot for now — the PVE backup jobs it would matter for are currently disabled — but worth resolving before they're ever turned back on, not after.
> [!WARNING]
> **A config that looks active but isn't.** Technitium's blocklist auto-update is configured with a 24-hour interval — but no actual blocklist URLs are set, so it's a dormant no-op: the schedule exists, nothing downloads. Same category of gap as the PBS prune job — a setting that reads as "handled" until someone actually checks whether it does anything.
--- ---
Related: [`docs/orchestration.md`](orchestration.md), [`docs/disaster-recovery.md`](disaster-recovery.md), [`docs/dashy-soc-board.md`](dashy-soc-board.md) · Stacks: [`stacks/platform/dashy/`](../stacks/platform/dashy/), [`stacks/platform/nocodb/`](../stacks/platform/nocodb/) Related: [`docs/orchestration.md`](orchestration.md), [`docs/disaster-recovery.md`](disaster-recovery.md), [`docs/dashy-soc-board.md`](dashy-soc-board.md) · Stacks: [`stacks/platform/dashy/`](../stacks/platform/dashy/), [`stacks/platform/nocodb/`](../stacks/platform/nocodb/)