After writing the updated script, _stop_event.set() caused a clean exit
(code 0). SCM failure recovery only fires on non-zero exit, so the service
stayed down permanently after every auto-update.
Fix: set _update_restart=True before signalling stop; SvcDoRun() checks
the flag after main() returns and calls sys.exit(1), which triggers the
sc.exe failure recovery chain (restart/5s/10s/30s configured at install).
The LocalSystem service account cannot access per-user Python installs
(AppData\Local\Programs\Python\...). When a per-user install is detected,
automatically install Python system-wide before proceeding.
- Detect per-user Python (AppData in path) and trigger system-wide install
- Extract system Python install logic into Install-PythonSystemWide function
- Check winget exit code before marking install successful
- Split pip install and postinstall into separate steps; pip failure is fatal,
postinstall failure is a warning (service DLLs may already be registered)
- Use $LASTEXITCODE check on pip rather than try/catch (external process)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Replace the scheduled-task approach (required user to stay logged in) with a
proper Windows Service using pywin32. The service runs as LocalSystem, starts
at boot, and auto-restarts on failure — no PowerShell window needed.
Agent changes (jarvis-agent-windows.py):
- Add Windows Service class via pywin32 (JarvisAgentService)
- Cleanly handles SvcStop by setting a threading.Event
- main() loop uses _stop_event.wait() instead of time.sleep() so stop is immediate
- self_update() signals the stop event when running as a service (SCM restarts it)
- __main__ block dispatches to SCM entry point or HandleCommandLine (install/stop/remove)
- Falls back to direct run if pywin32 not installed (for debugging)
Installer changes (install-windows.ps1):
- pip install pywin32 + postinstall (registers service runner DLLs)
- Python search prefers system-wide install (accessible by LocalSystem)
- Downloads Python 3.11 directly from python.org for Win 8.1 machines without winget
- Removes legacy JARVIS-Agent scheduled task if present
- Registers JARVISAgent service with --startup auto
- Configures sc.exe failure recovery (restart at 5s/10s/30s)
- Updated management commands in summary (Start-Service, Stop-Service, etc.)
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add version column to registered_agents table
- Agents send version on registration (Linux 3.1, Windows 3.0, macOS 3.0)
- workers_list API returns latest_versions per platform
- Workers tab: VERSION column with green check (up-to-date) or red (outdated)
- Outdated agents highlight row and show blue UPDATE button
- Up-to-date agents show dimmed UPDATE button
- Update button dispatches update command immediately
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Old installer wrote to /opt/jarvis-agent/config.json with server_url/api_key/
heartbeat_interval keys and pre-registered with JARVIS. Agent v3.0 expects:
- Config at /etc/jarvis-agent/config.json with jarvis_url/registration_key/
hostname/poll_interval/heartbeat_every keys
- api_key stored by agent itself in /var/lib/jarvis-agent/state.json
- Agent self-registers at startup using registration_key
Also adds: imagemagick install (headless screenshot support), apk support
for Alpine/WireGuard, copies to /usr/local/bin/jarvis-agent.py.
Previously agents only registered when api_key was missing (first run).
After updating to v3.0 with screenshot capability, restarted agents never
refreshed their capabilities in the DB. Now register() is called every
startup — server does UPDATE on existing agent_id so api_key is preserved.
self_update(cfg) and shell allow_shell_commands check both referenced cfg
from run() scope, but execute_command() is a standalone function. Fixed by
calling load_config() locally in each branch that needs it.
- 4-tier chat: HA control → Ollama → Groq → Claude
- Push-based agent system with heartbeat/metrics
- Network monitoring, alerts, Proxmox, Home Assistant
- Windows + Linux agent installers
- Stats cache cron, facts collector, KB engine