Updates to LARS: GRIDNET Core automatic updates!

GRIDNET OS - Main
1

Hi Operators,

We’re excited to announce a significant upgrade to LARS (GRIDNET Core Autonomous Crash Reporter & Liveness Service), version 1.8.3. This isn’t just a minor tweak; it’s a substantial overhaul focused on making GRIDNET Core operation significantly more robust, automated, and resilient to common environmental issues and update challenges.

How to Get It:
You don’t need a separate download for LARS! The latest version is now bundled directly within the main GRIDNET Core Installer. Simply download and run the latest installer from the official source:

https://gridnet.org/GRIDNETCore.zip

Running this installer will deploy both the latest GRIDNET Core and the enhanced LARS v1.8.3. As part of the improved integration, LARS should now launch automatically after the GRIDNET Core installation completes successfully.

What’s New & Why It Matters (The Deep Dive):

This release focuses heavily on intelligent automation and handling tricky edge cases:

  1. Self-Healing Installation & Repair:

  • Problem: LARS previously assumed GRIDNET Core was correctly installed. If Core was missing or key files were corrupted, LARS couldn’t start it.

  • Solution: LARS now actively checks for GRIDNET Core.exe at startup in standard locations. If it’s missing, LARS automatically triggers a full download-extract-install sequence . It fetches the latest installer ZIP, unpacks the MSI, and runs a silent installation (msiexec /i … /qn TARGETDIR=…) to either perform a clean install or repair a potentially damaged existing one.

  • Benefit: Nodes can now automatically recover from common installation issues or accidental file deletions without manual intervention.

  1. Fully Automated, Self-Updating Mechanism (Core & LARS):

  • Problem: Keeping both GRIDNET Core and LARS itself up-to-date manually across many nodes is time-consuming and error-prone. Updating a monitoring service while it’s running presents unique challenges.

  • Solution: LARS now incorporates a sophisticated, multi-stage auto-update process:

    • Version Check: Periodically (approx. every hour, configurable), LARS securely queries bootstrap.gridnet.org for the latest official Core version string. This check only proceeds if LARS was able to successfully read the current version from the local CoreVersion.txt file (preventing unnecessary updates if the local state is unknown).

    • Update Trigger: If the API reports a version newer than the current g_currentVersion, the update sequence begins.

    • Disk Space Pre-Check: Before downloading anything, LARS verifies there’s at least 2GB of free space on the target installation drive (C:\Program Files by default). If not, the update is safely aborted and logged, preventing failures due to insufficient space.

    • Graceful Core Shutdown: LARS signals the running GRIDNET Core.exe process to terminate (using TerminateProcess with exit code 0) and waits briefly to confirm its exit. Associated procdump.exe instances are also terminated.

    • Universal Uninstall: Critically, LARS now uses the stable UpgradeCode for GRIDNET Core to find all previously installed versions via MsiEnumRelatedProductsW. It then attempts a silent uninstall (msiexec /x {ProductCode} /qn MSIRESTARTMANAGERCONTROL=Disable) for each one found. The MSIRESTARTMANAGERCONTROL=Disable flag is crucial – it prevents the uninstaller from trying (and failing) to kill the running LARS process. Uninstall errors (like files being locked by the running LARS) are logged but don’t halt the process, ensuring maximum cleanup effort.

    • The “Sorcery” - LARS Self-Rename: To allow the new LARS executable to be installed, the currently running LARS performs a neat Windows trick: it renames its own executable file on disk (e.g., CrashUploader.exe to CrashUploader.exe.old). The process continues running from memory! This frees up the original filename for the installer. Failure at this critical step aborts the update.

    • Download/Extract/Install: LARS downloads the latest ZIP, extracts the new MSI, and executes a clean silent install (msiexec /i … /qn TARGETDIR=…). This installs both the new Core and the new LARS executable.

    • Post-Install Verification: After the MSI reports success, LARS verifies that the GRIDNET Core.exe file actually exists at the target location.

    • Version File Cleanup: The old CoreVersion.txt file is deleted, allowing the new Core instance to write its correct version on its first run.

    • Handover & Self-Termination: LARS briefly waits to see if the MSI automatically launched the new LARS instance (by checking for more than one LARS process). If not detected, the old (renamed) LARS manually launches the new LARS executable from its installation path. Once the new LARS is running (either detected or manually launched), the old LARS instance signals itself to terminate gracefully.

    • Rollback Attempt: If any step after the self-rename fails (install fails, new LARS can’t be found/launched), the old LARS attempts to rename itself back from .old to its original name to restore the previous state and aborts the update.

  • Benefit: Fully automated, hands-off updates for both Core and LARS, designed to handle complex scenarios like file locks and ensuring a clean installation state.

  1. Proactive Liveness Assurance:

  • Problem: Simply waiting for a crash isn’t always enough; processes can hang or enter unproductive states.

  • Solution:

    • Scheduled Restarts: LARS now enforces a mandatory restart of GRIDNET Core every 12 hours . This acts as a preventative measure, periodically refreshing the Core process state. These restarts are logged clearly and are not treated as crashes (no dumps generated, crash count unaffected).

    • Stall Detection Framework (Foundation): While not active yet, the internal structure is prepared to monitor key metrics from files in the stats directory (like BCHeight.txt). Future updates can easily enable checks like “Restart Core if BCHeight hasn’t changed in 3 hours,” triggering the same graceful restart mechanism used for scheduled restarts.

  1. Robust Startup & Environment Sanitization:

  • Problem: Leftover processes or conflicting system settings could interfere with monitoring.

  • Solution:

    • Singleton & Cleanup: On startup, LARS now actively searches for and terminates any other running CrashUploader.exe instances and any orphaned procdump*.exe processes using TerminateProcessL (which includes a taskkill /F fallback for stubborn processes).

    • Clean Slate: Immediately clears the contents of the GRIDNET_CrashDumps directory to avoid confusion with old dumps.

    • System Dialog Suppression: Attempts registry changes (requires Admin rights) to disable both the JIT Debugger pop-up and the Windows Error Reporting (“Application has stopped working”) dialog. This maximizes the chance that procdump can capture a clean crash dump without user interaction or system interference.

    • Clear Logging Info: Provides immediate console and MessageBox feedback on startup indicating where the detailed GridnetCrashReporter.log file can be found.

What This Means for Operators:

  • Set-and-Forget (Almost): LARS aims for near-total automation of installation, updates, restarts, and crash handling.

  • Maximum Uptime: Proactive restarts and future stall detection minimize downtime compared to only reacting to crashes.

  • Resilience: Designed to handle common failure scenarios like failed uninstalls, missing files, insufficient disk space, and locked executables during updates.

  • Improved Diagnostics: Cleaner dump handling and suppression of interfering system dialogs lead to more reliable crash data when needed.

We believe these enhancements represent a major step forward in the autonomous operation and stability of GRIDNET Core nodes. Please ensure you are running the latest GRIDNET Core installer to benefit from this updated LARS version.

As always, monitor logs for insights into LARS’s operations, especially during updates or if unexpected behavior occurs.

Best Regards,

The GRIDNET Team