v2.8.3

Highlights

• Windows: command cleanup can no longer terminate unrelated processes. After a command exited, the agent walked the process table from the command's PID by parent ID and terminated everything it reached. Windows reuses PIDs and keeps a dead parent's PID on its orphans, so that walk could reach processes the command never started, including system processes. The walk is gone: each command now starts suspended, is placed in a job object before it runs, and is cleaned up only through that job and the agent's own handle to the root (#566).
• Windows: one log line per command cleanup. Command ID, root PID, reason, whether the job was assigned, how many job members were still active and whether the root was killed, at Info when something was killed and at Warn when the cleanup itself failed (#566).

Fixes and improvements

• Uninstall without systemd: the deferred package removal now runs in its own session, so the command's exit cleanup no longer kills it (#566).
• Sudo: the approval request carries the run-as user the PAM plugin reports; older servers ignore the field and older plugins leave it out (#560).
• Collector: batch commit errors are returned and raw rows are pruned inside the save transaction (#559).
• Self-upgrade: the restart is deferred on hosts without systemd (#529).
• Executor: the output tail buffer is compacted in place (#527); command chunk uploads are bounded and retried with backoff (#554).
• Runner: HTTP connections to Alpacon are reused across reports and downloads (#525); the agent reports the execution lanes it supports (#548).
• Dependencies: Go 1.26.9 and patched x/crypto, x/text and x/mod (#555).

Upgrade note: on Windows, commands still running, and any background work a command started, end when the agent process exits, restarts or is reinstalled, because the job is killed when the agent's handle closes. Work that must outlive the agent has to run as a scheduled task or a Windows service rather than from a command. Alpacon defers upgrades and restarts while a server has an open Websh or WebFTP session or a running command unless forced, so this normally affects only work started after the upgrade was dispatched. See Windows servers → Upgrades.