Recent content by dakralex

The SIGSEGV is a very different cause to end a process here, so that seems quite unrelated to the previous SIGABRT signals. Could you specify the hardware these cluster nodes are running on? Does a longer-running memtest or a stresstest with e.g. stress-ng show any signs of hardware failure?

Unfortunately, we don't have any way to reproduce this on our end yet. One way to be able to have some more information about this would be to look at the process' coredump as a SIGABRT will cause this. See if there is any coredump related to these issues in /var/lib/systemd/coredump/ (see [0]...

The safest procedure to disarm the HA stack before these disarm-ha/arm-ha commands were introduced is to stop the pve-ha-lrm service on each node individually, and after these are all confirmed to be 'restart mode' and all HA resources in 'freeze' by ha-manager status and then the pve-ha-crm...

I don't think that pvestatd is related to this issue, because neither pve-ha-crm nor pve-ha-lrm directly depend on pvestatd. I haven't found any clues why pve-ha-lrm in particular is killed with SIGABRT... How was the HP modules blacklisted? Was the pve-ha-lrm.service systemd unit changed in...

Have you started the affected container during the time of this log? You can use journalctl --since '2026-06-12 09:38:00' --until '...' to capture the output between some time span (I filled in the --since with the rough start time of the LXC from your top post). Adding --no-pager might help in...

Does the pve-ha-lrm service acquire its lock on pve1 and pve3 correctly?

Thanks, could you also provide the kernel syslog for the boot before the node rebooted itself?

Hi! Does this happen on a specific cluster node or all cluster nodes? What kind of watchdog is used on the node(s) where this happens? Are there any kernel parameters set? Does any other software on the cluster nodes compete for the /dev/watchdog device? Otherwise, it would still be good to...

No worries, and the manual can always be improved though I didn't put in the technical explanation from above as it felt too specific. If it's useful there as well, I can certainly find a way to put it there without being too distracting from the main functionality ;)

Hi! In more detail, each node's current cpu and memory usage is normalized with its own capacity (i.e. cpu_load = current_cpu / max_cpu and memory_load = current_memory / max_memory), where the node's current load is then a equal-weighted average of that (i.e. (cpu_load + memory_load) / 2...

Hi! Yes, this is a known issue and is currently tracked with this Bugzilla entry [0]. [0] https://bugzilla.proxmox.com/show_bug.cgi?id=7053

Thanks for the infos! It's a bit unfortunate that the log doesn't have any entries before the error to know on what tasks the LRM was currently working on. Can I assume that the node is the ballpark of ~33+ nodes according to the names? How many max_workers are configured in the datacenter...

Could you share the full log of pve-ha-lrm on the node where it crashed before the "Attempt to free unreferenced scalar" error? And preferably the HA configuration (resources.cfg and rules.cfg) and the log output of the pve-ha-crm on the active master node at that time in the same time slice as...

Hi! Can you share the log for the HA Manager on the current master node (e.g. with journalctl -u pve-ha-crm)? The master node is listed in ha-manager status.

As a follow-up and to eliminate other possible causes: Have such segfaults or memory corrupts happened before on the node? If some maintenance time is possible, does a memtest with a few runs end successfully?