How do i setup services identification properly on my proxmox node and underlying lxcs #1657
Answered
by
pulse-triage
Bot
Return to top
|
I have added the proxmox node by using Settings -> Infra -> Add Proxmox VE -> Host telemetry agent Scope of API All i see is "Service not identified" I checked the API logs to api/discovery/system-container/08f4949f-0275-4b4e-a82c-7ea01c794c2c-ff75604 with this response: what am i missing with the config |
Answered by
pulse-triage[bot]
Aug 12, 2026
Replies: 10 comments 1 reply
|
Good news: the response you pasted already contains the exact diagnosis, in its Pulse talks to your node over two separate channels. Telemetry (metrics, hostnames, the stuff your dashboard already shows) is one; command execution is the other. Service identification for an LXC works by running commands inside the container, routed through the host agent as Why the command side is dead even though your agent is connected: the "Host telemetry agent" setup path you used deliberately mints a least-privilege token. The repo's own test suite asserts this: the deploy flow's runtime token is asserted to carry report, config:read, and manage, and explicitly NOT agent:exec ( The fix, using the app's own guidance strings as the map:
One way to confirm which state you are in before and after: the UI distinguishes "Agent not connected for command execution. The API token may be missing the agent:exec scope. Check Settings -> API Access." from the no-agent-at-all variant ( Caveat for honesty: this is verified against today's main branch source, and your instance's |
0 replies
|
@RenSolvyn - I am still confused. I took your suggestion and reinstalled and seems it has created a new api token for the same as well 
I can see I checked the pulse logs and found these - it says pulse-agent logs from the pve node which I am not sure if it will be helpful to you. Please do let me know what other aspects can i check |
0 replies
|
Thanks for the logs. I found the cause: service discovery dropped the tenant-scoped command executor during initialization, even though the same connected agent could handle other commands. The fix is now on Image: Please back up your Pulse data first and, if practical, test this outside your primary instance. This is an issue-specific diagnostic build, not a stable or RC release. It contains the normal Pulse server runtime but omits embedded installer and agent-download artifacts, so please use it only to repeat this service-discovery test. Pin the digest in Compose by replacing the Pulse service image with: image: rcourtman/pulse@sha256:feb69ba07ed13b51a7e048f97b99ffa82862ef18c46ee5041fccb272523e964fThen pull and recreate only the Pulse service: docker compose pull pulse
docker compose up -d pulseConfirm Pulse reports If it still fails, please attach the fresh Pulse server logs from that discovery attempt, especially entries containing Rollback image: After restoring that image in Compose, run: docker compose pull pulse
docker compose up -d pulse |
0 replies
|
I am running pulse within an proxmox lxc using binaries. So i dont think i can swap docker images. I might need to build the binary and replace it under As per what you say i wont need to build and replace every binary rather only the pulse binary and restart the service right |
0 replies
|
Yes, only the To match the tested build exactly git clone https://github.com/rcourtman/Pulse.git
cd Pulse
git checkout dfcfe3fbd
npm --prefix frontend-modern ci
npm --prefix frontend-modern run build
go build -ldflags "-X main.Version=v6.2.1+test.1657.dfcfe3fb" -o pulse ./cmd/pulseThe frontend build has to run first because the UI is embedded into the binary at compile time, so you need Go 1.26 and a current Node with npm. The ldflags stamp lets you confirm the running build afterwards. An unstamped binary reports a dev version. Stop the Pulse service, back up |
0 replies
|
@rcourtman - After building and trying out the latest version after building as suggested, when i run the discovery, its not failing like before. Is this the expected result? Pulse logs:
Pulse Agent Logs: POST - After testing the above i reverted to the prior binary and see a strange issue. See the 
|
0 replies
|
Yes, that is the expected result. The record still showing an empty service name at low confidence is the analyzer's own verdict over the collected outputs, separate from the executor bug. Identification quality is worth its own look if it stays poor for obvious services like Open WebUI. The docker report 403 is a token scope gap. The token your host agent authenticates with does not carry On the Agent Update and Credentials invalid tags after reverting, those are the server's connection health verdicts and Credentials invalid means the source rejected the stored credential path. Give it a restart and one collection cycle. If either tag persists, open Manage on that host row and post what the credential health detail says. |
1 reply
|
Thanks, I have added the docker related token scope gap for the 403 error you helped identify "Agent Update" got resolved after a pulse lxc restart while the credentials invalid still exists. When i click on Manage against the host row, a pop up appears but i dont see anything saying "credential health detail". where do you want me to get this info from |
Answer selected by
jenishngl
|
The Manage dialog was the wrong pointer, sorry. The detail shows in the sources table itself, a failing host row gets a red error line directly beneath it carrying the source's actual rejection text, and that text is what I need. Credentials invalid means a poll got a 401 or 403 back from the node for the stored token. If there is no red line under the row, paste the Pulse server log lines around a poll cycle instead, filtered for the node name or 401 or unauthorized. |
0 replies
|
Before i grab all the logs, i wish to clarify if i have followed the correct installation step to add the nodes in Pulse. I have a pve cluster containing 2 nodes and i click on discover and i see both the individual nodes, i pick the cluster main node first, review and accept the discovery and copy the install Should i run any commands on the 
I looked at the Agent Docker and i see this. So I created a token from the Agent Doctor window to create a repair command but that as well when executed said 
|
0 replies
|
Your install flow was right and nothing else is missing for API monitoring, accepting one discovered node covers the whole cluster. The Host Telemetry Agent is per node though, the install command only covers the machine you run it on, so each node that should report host telemetry needs it run once. ngl-server2 already has an agent on it from your earlier test builds, which is why it shows Agent and Active, but that agent is presenting a token this server no longer recognises, and that is the Credentials invalid line. The repair command is host local, run it on ngl-server2 itself. If it still says no installation found there, the old agent went in under a non-standard path, in which case run the full Host Telemetry Agent install command on ngl-server2 instead, it replaces the old install and enrols with a fresh credential. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Yes, that is the expected result.
scan_completedwith outputs and no errors means theexecutor_missingfailure this thread was about is gone. The fix is onmainand lands in the next release, so you can restore your backed up 6.2.1 binary when that ships rather than staying on the test build.The record still showing an empty service name at low confidence is the analyzer's own verdict over the collected outputs, separate from the executor bug. Identification quality is worth its own look if it stays poor for obvious services like Open WebUI.
The docker report 403 is a token scope gap. The token your host agent authenticates with does not carry
docker:report, so Docker reports are rejecte…