FailedProxy/Varaverk
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: remove all User Scripts dependencies — Varaverk plugin handles everything via event hooks, no User Scripts needed

Browse Source
This commit is contained in:
Gmer4Lfe
2026-06-01 19:57:21 -04:00
parent 98d2e6efa4
commit e0ae80d2ea
9 changed files with 65 additions and 75 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Orchestrators/README-Orchestrators.md
+24 -24
View File
@@ -7,10 +7,10 @@ Orchestrators contain no business logic — they call other scripts in order, tr
pass/fail per job, and produce one clean summary. Configuration lives in `master.conf`.
Adding or removing a job never requires touching the orchestrator script itself.
> **The User Scripts plugin contains only orchestrators.** Every cron entry, every
> "At Startup of Array" entry, every scheduled operation runs through an orchestrator.
> The individual scripts it calls are never scheduled directly — they run in a defined
> order inside a coordinated window, with a unified summary at the end.
> **The Varaverk scheduler runs only orchestrators.** Every cron entry, every array
> start/stop event, every scheduled operation runs through an orchestrator. The individual
> scripts it calls are never scheduled directly — they run in a defined order inside a
> coordinated window, with a unified summary at the end.
---
@@ -80,28 +80,28 @@ import has already been replaced by a working one. No manual intervention requir
### 🔴 Array Start Scripts Running in Wrong Order or Not at All
Scripts configured in the User Scripts plugin as "At Startup of Array" run in an
unpredictable order. The ramdisk setup might run after Emby starts. The syslog
filter might run after containers have already created veth interfaces. PHP-FPM
tuning might run after the WebGUI has already served its first requests. Each
script competes for the same startup slot with no guaranteed order.
Startup scripts configured individually ran in an unpredictable order. The ramdisk
setup might run after Emby starts. The syslog filter might run after containers have
already created veth interfaces. PHP-FPM tuning might run after the WebGUI has already
served its first requests. Each script competed for the same startup slot with no
guaranteed order.
The fix: `array_started.sh` is the only "At Startup of Array" entry. It launches
every startup script in a defined order, with one-second settle between each, and
reports which succeeded and which failed. Order is guaranteed. Nothing starts before
its dependency. Everything is visible in a single summary.
The fix: `array_started.sh` is the only array-start entry in the Varaverk scheduler.
It launches every startup script in a defined order, with one-second settle between
each, and reports which succeeded and which failed. Order is guaranteed. Nothing starts
before its dependency. Everything is visible in a single summary.
---
## ━━━ THE ORCHESTRATOR MODEL ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The Varaverk scheduler (and User Scripts for array start) contains exactly these entries:
The Varaverk scheduler contains exactly these entries:
```bash
# At Startup of Array — single entry for all startup scripts:
# Array start event (Varaverk disks_mounted hook → cron: "array_start"):
array_started.sh
# Cron — one entry per maintenance window:
# Cron — managed via Varaverk Scheduler:
*/7 * * * * transcode_management.sh
*/15 * * * * watchdog_orchestrator.sh ← resource → docker → system → stability
*/30 * * * * critical_sync_maintenance.sh ← auth + Emby dirty sync + partnership
@@ -169,7 +169,7 @@ without `--log`.
| Script | What It Orchestrates | Schedule |
|--------|---------------------|----------|
| `array_started.sh` | All array startup scripts in order | At Startup of Array |
| `array_started.sh` | All array startup scripts in order | `array_start` event (Varaverk plugin hook) |
| `watchdog_orchestrator.sh` | resource → docker → system → api_renew → stability watchdogs | Every 15 minutes |
| `transcode_management.sh` | Cleanup then manager — order critical | Every 7 minutes |
| `arrs_failed_stalled_recovery.sh` | Failed import + stalled download recovery | Every 6 hours |
@@ -184,13 +184,13 @@ without `--log`.
## 🚀 array_started.sh
## ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Single "At Startup of Array" entry for the entire ecosystem. Launches every startup
script in order — each as a background process — and reports which succeeded and which
failed. You never need to add individual scripts to the User Scripts startup list.
Single array-start entry for the entire ecosystem. Fired by the Varaverk plugin's
`disks_mounted` event hook. Launches every startup script in order — each as a
background process — and reports which succeeded and which failed.
```bash
# Scheduled: At Startup of Array (User Scripts plugin)
# This is the ONLY "At Startup of Array" entry in User Scripts
# Triggered by: Plugin/unraid/event/disks_mounted/array_start_jobs
# schedule.json entry: "Orchestrators/array_started.sh" → cron: "array_start"
```
---
@@ -266,7 +266,7 @@ ARRAY_START_SCRIPTS=(
```bash
# ─────────────────────────────────────────────────────────────────────────────
# Normal — called by User Scripts at array start. Never run manually in production.
# Normal — fired by Varaverk disks_mounted event hook. Never run manually in production.
# array_started.sh runs once and exits — the continuous scripts it launched
# keep running as background processes.
# ─────────────────────────────────────────────────────────────────────────────
@@ -888,7 +888,7 @@ monthly_maintenance.sh --log # verbose output from each child script
```bash
# ─────────────────────────────────────────────────────────────────────────────
# At Startup of Array — single entry:
# Array start event (Varaverk disks_mounted hook):
# ─────────────────────────────────────────────────────────────────────────────
array_started.sh