Issues Fixed in Lightbits 3.12.2
| ID | Description |
|---|---|
| 36090 | Due to a rare internal error, involved long network disconnections nodes might lose service and stay in Inactive state - even though the node should be active. |
| 35837 | On a single-instance service on a machine with multiple numa-nodes with memory, memory stress can occur, and the kernel will try to perform memory reclamation. This leads to start failures in the duroslight service, with the node staying inactive. |
| 35611 | The progress during power-up may appear to get stuck at 10%. However, the process will eventually continue. This behavior is only a visual delay and does not affect the overall progress of the power-up process. To monitor the progress, you can use the following command: cat /mnt/debug/lb_backend/<instance_id>/recovery/recovery/num_completed_trim_units. |
| 35572 | When enabling encryption with TPM, there are some servers that could respond slowly to TPM, causing a race condition between TPM and our standard health checks and heartbeats. If this happens, one of more of the nodes could become inactive for awhile, and then they should be revived and become active again. Once this happens, there is a need to validate if the encryption passed or not using the get clusterinfo API. If encryption remains disabled, there is a need to run the enable encryption API once again. |
| 35340 | Under certain circumstances, the TPM access completely jams the go runtime scheduler, preventing any other go-routines spawned by the running service from running. This could lead to Lightbits nodes becoming temporarily inactive, and could cause enable encryption to fail. |
Was this page helpful?