Replies: 11 comments 2 replies
|
Hi , I'm not running any "Pulse agent" on it to keep it small/nice/clean/secured if i run I would like to know how you've got the list of temperatures and the timings. Could you share ? If i can help... |
|
I know the disks are too hot. You should have seen them before! hitting 90 C, they did not last long. Was changing one out, once a week or so LOL. One of the unintended side effects of cramming 2, 5 bay disk modules into a gaming case, I affectionately call nibbler. I need to swap out my 5 bay modules as the fans have died. They are old! Just FYI, this system was built using mostly discarded parts. I have a box of spare disks for now. LOL my zpool appears to be fine though. I can run a scrub and see if anything pops up. But that should not effect the smartctl scans that pulse does right? Checking temps manually is not the issue. Only pulse fails. I tried also to configure a wrapper for smartctl to get it to pull data more quickly. That did not help. For temps. I use:
To time commands, just put "time" in front of the command.
|
|
The three messages together point at the probe rather than the disks. The agent asks smartctl --scan how to address each device, and behind a SAS HBA SATA drives commonly enumerate as -d scsi. Probed that way a SATA drive returns none of the ATA data your manual run gets through automatic sat detection, which would take out health, serial and temperature in one go. The agent also adds a standby guard on rotational disks that some SAS topologies answer incorrectly. Outputs from the Proxmox node that would pin it: plus the agent version Pulse shows for that host and any smart related lines from its agent log. Posted by an automated triage run. rcourtman reviews everything it does. See the AI transparency statement. |
|
The SMART identity, health, and temperature values come from the Unified Agent on the Proxmox host; they are not supplied by the PVE API disk-list request. Current v6.2.1 automatically handles the exact SAT-behind-SAS shape shown here. Commit 25b2df0 makes the agent treat a disk whose SCSI-layer vendor is ATA as SATA even when the HBA exposes a SAS address, so it retains the -d sat probe instead of trusting the smartctl --scan -d scsi hint. There is no manual probe override to configure. Because this was reported on v6.1.2, which should already contain that change, please post: If the agent is older than v6.2.1, update it first and repeat the last command after one collection cycle. If it is current, those evidence lines will show whether this is a remaining probe-selection regression or a different collection failure. The Failed to get disk list timeout is a separate PVE REST collection path. It can explain incomplete API inventory, but it does not prevent a working Unified Agent SMART report from supplying the disk telemetry. |
|
I updated pulse, and started over removing the agent and the API tokens. Re-added nibbler as if pulse were a fresh installation. I ran the commands requested: All of my disks show listed in the Physical Disks section, but unfortunately that is all I get: Infrastructure shows that nibbler is active for both API + Agent: Pulse Agent Doctor report (2 agents; 2 healthy) nibbler (nibbler)
nibbler (Host agent)
Please let me know if there is any more information that I can provide. Thanks, |
|
Progress. The rows you pasted come from the PVE API inventory, which is now working, that is where the identity and serials come from. Temperature and health are enriched separately by the agent's smartctl collector, and that collector logs its probe decisions and failures only at debug level, so your empty journal grep does not tell us whether it ran clean or failed. That is the missing evidence. Set the agent to debug for one collection cycle: sudo systemctl edit pulse-agentAdd this drop-in, then save: [Service]
Environment=LOG_LEVEL=debugThen: sudo systemctl daemon-reload
sudo systemctl restart pulse-agent
sleep 180
journalctl -u pulse-agent --no-pager --since "-5m" | grep -iE "smartctl|smart" | tail -60Revert afterwards with Posted by an automated triage run. rcourtman reviews everything it does. See the AI transparency statement. |
|
|
That log narrows it. The two disks that collected are your SSDs, which the agent probes without its spin-up guard. All ten failures are the rotational disks behind the SAS3224, and every probe on those carries the guard, while your manual run that worked used -d sat without it. So the open question is what the guard's power-mode check does through this HBA's SAT translation. Please run these two, they are the agent's exact invocations, and paste both outputs in full with the exit lines That pins whether the guard aborts, the query comes back empty, or the data is there and the agent is mis-parsing it, and each of those is a different fix on my side. Posted by an automated triage run. rcourtman reviews everything it does. See the AI transparency statement. |
|
Root cause found without needing the outputs after all, though they are still worth running. smartmontools 7.5, which your host carries, started reporting the power state as a structured JSON object whenever the agent's spin-up guard is active, and the guard is applied exactly to rotational disks. The agent's parser expected the old shape, so the whole reading failed and every spinning disk degraded to "no usable SMART data" while your two SSDs, probed without the guard, kept working. Your log's rotational-only split is that bug precisely. Fixed on main in a399351 and it lands in the next release, please retest on it. The two commands from my last comment still settle one remaining question, if they print exit=0 the release restores temperatures and health outright, and if they print exit=3 your HBA is also misreporting spinning disks as standby, which the fixed agent would then show as disks in standby, and that would be the next thing to chase. Posted by an automated triage run. rcourtman reviews everything it does. See the AI transparency statement. |
|
|
Thanks, those outputs settle it. Both probes exited 0 and the drive reports ACTIVE or IDLE, so the standby guard behaves and your HBA is not misreporting power state. Your paste also shows the exact culprit. smartctl 7.5 returns The fix is in v6.2.2-rc.2, published earlier today as a pre-release. Your sda already returns PASSED and 58 C with the guard active, so temperatures and health should come straight back once the parser accepts the new shape. To test now on your Docker install, point your compose file at the release candidate image, The The agent on nibbler updates itself from the server, so it should move to the new version within a few minutes of the container coming back. If you would rather stay on stable, the same fix ships in v6.2.2. One last thing, remember to revert the debug logging with |
Uh oh!
There was an error while loading. Please reload this page.
Having issues with pulse monitoring my standalone proxmox node. Looking for some guidance.
I have 10 x 2TB, SATA HDDs for my ZFS pool. They are connected to their own HBA, Serial Attached SCSI controller: Broadcom / LSI SAS3224 PCI-Express Fusion-MPT SAS-3 (rev 01).
Prior versions of pulse would monitor these just fine. Now it is hitting a timeout or something just getting the list of disks.
I am guilty of spending lots of time with AI, trying different things, with no joy.
Pulse is running in a docker container on a Raspberry pi 5, using a USB 3.0 external SSD. Not the best, but what I got for now. It runs pretty decent and snappy.
Running smartctl commands pulling temps from CLI runs about 3 seconds on average.
Previously pulse was running on a VM on my node, but that doesn't make too much sense, does it LOL.
Any insight or guidance is very much appreciated. Is there a way to increase the timeout. I don't mind if the disks are monitored every 30 minutes even. I tried changing the poll settings as well as the smart poll frequency, with no help.
Closest I got was it getting half way through listing some of the details of the disks, if that helps.
I am on 6.1.2 - yes I removed all of the old agents and proxys. I have started over a few times already just to be sure.
context deadline exceeded (Client.Timeout exceeded while awaiting headers)","component":"pulse","time":"2026-08-06T22:13:20-04:00","message":"Failed to get disk list"}
Yes my disks are hot! Working on some modifications of the case.
/dev/sda: 60
/dev/sdb: 63
/dev/sdc: 58
/dev/sdd: 64
/dev/sde: 64
/dev/sdf: 64
/dev/sdg: 57
/dev/sdh: 59
/dev/sdi: 62
/dev/sdj: 56
real 0m4.117s
user 0m0.160s
sys 0m0.061s
This is what I see in Physical Disks on pulse web ui:
Unknown
Health state is not reported.
Serial number is unexpectedly missing: disk serial was not reported
Temperature is temporarily unavailable: SMART probe returned no usable temperature data
Thanks,
Rob
All reactions