Patching and Pallas

A patching agent shows offline or not answering

Diagnose, on the endpoint (Linux):

systemctl status theseus-agent
journalctl -u theseus-agent -n 100

macOS: sudo launchctl print system/com.theseus.agent and /var/log/theseus-agent.log. Windows: the scheduled task \Theseus\Theseus Agent in Task Scheduler.

On the server:

cd /opt/theseus && sudo ./theseus logs patch-service

Finding	Cause	Fix
The agent logs the server refuses this agent (revoked or unknown)	The enrolment was revoked, the machine removed, or its key changed	Re-enrol the machine: run the install command again with --patching
Connection errors to https://<host>/agent	443 blocked, or a proxy with a short idle timeout	Allow 443; idle timeouts of at least 60 s
Agent running, console says Mapping incomplete	First contact has not mapped it to its Wazuh agent yet	Check the Wazuh agent is connected; wait a few minutes
macOS with FileVault, after a restart	The Mac reconnects only after a user logs in	Log in once

A patch job is blocked

The job's detail says why. Common reasons: the finding is stale (already fixed), the machine is not mapped yet, the machine is disabled ("enable it on the Agents page first"), it is unreachable, or a safety policy refused the plan (deny-listed package, reboot not allowed, more than one host). Fix the cause and start a new job.

A patch job stays in "Verifying"

Cause. Verification waits for independent proof: the Wazuh agent restarted and reporting the new inventory, then vuln-verify confirming every fixable vulnerability. vuln-verify is asked to re-check after 5 minutes and then every 10; its regular cycle is 30 minutes.

What to expect. Up to 90 minutes. Then the job ends:

• Remediated, when confirmed (or when every vulnerability row is gone and the installed version was proven);
• Reboot required, when the fix needs a restart (kernels): use Reboot now inside the machine's maintenance window, with Allow reboot set on the machine;
• Not verified (engine did not confirm remediation within 90min), otherwise.

Diagnose.

sudo ./theseus logs patch-service
sudo ./theseus logs vuln-verify

Check the Wazuh agent on the machine is Connected: without fresh inventory, nothing can be confirmed. In a two-server install verification uses vuln-verify's regular cycle, so it takes longer.

A job that ended Not verified can be marked handled; check the machine and start a new job if the vulnerability is still open.

Reboot refused

Message	Fix
asset does not allow reboots (set allow_reboot on the asset first)	Set Allow reboot on the machine
outside the maintenance window (<window> UTC) - try again inside it	Wait for the window, or change it

Pallas says the LLM is unreachable

Symptom. Answers end with "Automated analysis temporarily unavailable. Manual review of the data above is required." and "LLM analysis service is unreachable". AI analysis on alerts fails. Platform health shows AI / LLM degraded.

Diagnose.

cd /opt/theseus
sudo ./theseus config show | grep '^LLM_'
sudo ./theseus logs pallas

Test the endpoint from the server (an OpenAI-compatible endpoint lists its models):

curl -sS -H "Authorization: Bearer <key>" "<LLM_BASE_URL>/models" | head -c 400

Finding	Fix
LLM_BASE_URL empty or wrong (missing /v1)	Set it, for example https://router.huggingface.co/v1
401 or 403 from the endpoint	LLM_API_KEY wrong or expired
404 or "model not found"	LLM_MODEL is not served by that endpoint; pick one from /models
Certificate errors (CERTIFICATE_VERIFY_FAILED)	The endpoint's certificate is not from a public CA. Put your CA's certificate in runtime/pki/extra-ca.pem and apply (Private CA)
Timeouts	Outbound access from the server (the application server, with two servers) to the endpoint
429	The endpoint's rate limit or quota

After changing LLM settings, apply them (ask us, or sudo ./theseus config apply).