@Rocky what these error means Normal Scheduled 9m58s default-scheduler Successfully assigned starrocks-dev/starrocks-shared-data-cn-3 to aks-clickhouse1-31600135-vmss00001u Normal SuccessfulAttachVolume 9m52s attachdetach-controller AttachVolume.Attach succeeded for volume "pvc-984ce813-c004-4352-a113-ebdeb6ba7d05" Warning Unhealthy 5m43s kubelet Liveness probe failed: Get "10.92.40.92/api/health": dial tcp 10.92.40.928040 connect: connection refused Warning Unhealthy 5m42s kubelet Readiness probe failed: Get "10.92.40.92/api/health": dial tcp 10.92.40.928040 connect: connection refused Warning Unhealthy 33s kubelet Liveness probe failed: Get "10.92.40.92/api/health": read tcp 10.92.16.23748548 >10.92.40.928040: read: connection reset by peer Warning Unhealthy 33s kubelet Readiness probe failed: Get "10.92.40.92/api/health": read tcp 10.92.16.23748564 >10.92.40.928040: read: connection reset by peer Warning BackOff 27s (x3 over 29s) kubelet Back-off restarting failed container cn in pod starrocks-shared-data-cn-3_starrocks-dev(fdcaf9ce-3684-4b34-8b80-35eb018bef2f) Normal Pulled 19s (x3 over 9m43s) kubelet Container image "starrocks/cn-ubuntu:4.0.0" already present on machine and can be accessed by the pod Normal Created 19s (x3 over 9m43s) kubelet Container created Normal Started 19s (x3 over 9m43s) kubelet Container started Warning Unhealthy 18s (x2 over 5m38s) kubelet Startup probe failed: Get "10.92.40.92/api/health": dial tcp 10.92.40.928040 connect: connection refused [Tue Sep 1 064119 UTC 2026] Process conf file cn.conf ... [Tue Sep 1 064119 UTC 2026] Add myself (starrocks-shared-data-cn-28.starrocks-shared-data-cn-search.starrocks-dev.svc.cluster.local:9050) into FE ... ERROR 1064 (HY000) at line 1: Compute node already exists with same host starrocks-shared-data-cn-28.starrocks-shared-data-cn-search.starrocks-dev.svc.cluster.local and port 9050 [Tue Sep 1 064119 UTC 2026] run start_cn.sh

The logs you provided indicate two main things: a registration conflict and a process startup failure. The registration error (1064) is usually a "red herring" (not the root cause of the crash), while the probe failures indicate that the Compute Node (CN) process is failing to start or crashing immediately after it tries to launch. 1. The "Compute node already exists" Error (MySQL 1064) In the StarRocks Kubernetes entrypoint script, the container tries to register itself with the Front-End (FE) using a SQL command (

ALTER SYSTEM ADD COMPUTE NODE ...

). * What it means: The FQDN (e.g.,

...cn-28...

) is already in the FE's internal list of nodes. This happens if the pod restarted or if a previous pod with the same name didn't unregister properly. * Is it fatal? Usually no. Most StarRocks container scripts treat this error as a warning and proceed to the next step:

run start_cn.sh

. The fact that your log shows

run start_cn.sh

right after the error confirms the script didn't stop there. 2. The Probe Failures (

connection refused

/

connection reset

) This is the real issue. Kubernetes is trying to check if the CN is healthy by hitting the health API on port

8040

, but the connection is being refused. * Startup Probe Failed: The CN process (

starrocks_be

or

starrocks_cn

) never successfully started and opened its web server. * Liveness/Readiness Probe Failed: The container is being restarted because it’s not responding. Common Causes for CN Startup Failures Since the script reaches

run start_cn.sh

but the process never listens on port 8040, the process is likely crashing immediately. Check these common culprits: 1. CPU Instruction Set (AVX2): StarRocks CN/BE requires AVX2 instructions. If your AKS node pool uses older VM types that do not support AVX2, the CN binary will crash instantly with a

SIGSEGV

or illegal instruction error. 2. Shared-Data Configuration: Since you are using

shared-data-cn

, the node must be able to connect to your object storage (S3/GCS/MinIO). If the storage endpoint, bucket, or credentials in

cn.conf

are incorrect, the process will fail to initialize and exit. 3. Memory Limits: If the pod's memory limit is too low, the process might be killed by the OS immediately during its initial memory allocation (StarRocks typically requires at least 4GB-8GB to start reliably). 4. Ulimits (Open Files): StarRocks requires a high number of file descriptors (at least 65535). If the Kubernetes node or pod security context restricts this, the process may fail. Recommended Next Steps To find the specific crash reason, you need to look at the logs generated after the registration attempt: * Check previous container logs:

bash
    kubectl logs starrocks-shared-data-cn-3 -n starrocks-dev --previous

* Check the CN standard output log: If you can

exec

into a crashing pod (or if you use a persistent log volume), look at:

/opt/starrocks/cn/log/cn.out

or

<http://cn.INFO|cn.INFO>

. * Verify AVX2 support on the AKS node:

bash
    kubectl run -it --rm --image=busybox node-check --restart=Never -- grep avx2 /proc/cpuinfo

(If this returns nothing, your VM nodes are incompatible with this StarRocks version.)

[Tue Sep 1 063706 UTC 2026] Process conf file cn.conf ... [Tue Sep 1 063706 UTC 2026] Add myself (starrocks-shared-data-cn-3.starrocks-shared-data-cn-search.starrocks-dev.svc.cluster.local:9050) into FE ... ERROR 1064 (HY000) at line 1: Compute node already exists with same host starrocks-shared-data-cn-3.starrocks-shared-data-cn-search.starrocks-dev.svc.cluster.local and port 9050 [Tue Sep 1 063707 UTC 2026] run start_cn.sh /opt/starrocks/cn_entrypoint.sh: line 165: 27 Segmentation fault (core dumped) $STARROCKS_HOME/bin/start_cn.sh $addition_args

Hello, @ansh.gupta2! How can I assist you today?

@Rocky i have provide the previous error log please check

Based on the logs and events you provided, your Compute Node (CN) is failing to start properly. Here is the breakdown of what these errors mean and how to fix them: 1. The Registration Error (MySQL 1064)

text
ERROR 1064 (HY000) at line 1: Compute node already exists with same host ...

* What it means: When the pod starts, a helper script tries to register the node with the Front-End (FE). This error indicates that a node with that specific hostname/FQDN is already in the FE's internal list. * Is it the cause of the crash? Likely no. Most StarRocks container scripts (like the ones in version 4.0.0) treat this as a warning and continue to the next step:

run start_cn.sh

. * A suspicious detail: Your Kubernetes events are for pod

cn-3

, but the logs show the node is trying to register itself as

cn-28

. This suggests a configuration mismatch where the pod's identity is being incorrectly reported or hardcoded, which might lead to heartbeats failing later. 2. The Probe Failures (

connection refused

)

text
Liveness probe failed: Get "...:8040/api/health": dial tcp ...:8040: connect: connection refused

* What it means: Kubernetes is trying to check if the CN is healthy by hitting port

8040

. "Connection refused" means the CN process is not running. * Root Cause: The log ends at

run start_cn.sh

. If the process were starting correctly, you would see further output or the container would stay alive. Since it is in a

BackOff

state, the

starrocks_be

(CN) binary is likely crashing immediately after the script tries to launch it. Common Reasons for Immediate CN Crashes in 4.0.0 Since the process dies before it even creates a log file (

<http://cn.INFO|cn.INFO>

), check these three primary suspects: 1. Missing AVX2 Instruction Set (Most Common): StarRocks binaries (especially version 3.x and 4.x) require AVX2 support on the physical CPU. If your AKS node pool uses older VM generations that lack AVX2, the CN will crash instantly with an

illegal instruction

or

Segmentation fault

. * Check this: Run

kubectl run -it --rm --image=busybox node-check -- grep avx2 /proc/cpuinfo

. If it returns nothing, your nodes are incompatible. 2. Known Startup Bug in 4.x: There is a documented issue in some 4.0.x/4.1.x versions where the CN process can segmentation fault during static initialization (before it even starts its logging system). This often happens due to specific environment variable configurations or host-name resolution issues. 3. Memory/Resource Limits: If the Pod has a low memory limit (e.g., < 4GB), the Linux OOM killer might terminate the process during its initial memory pre-allocation. Check the pod's exit status: * Command:

kubectl describe pod starrocks-shared-data-cn-3 -n starrocks-dev

* Look for

Terminated

with

Reason: Error

or

OOMKilled

and check the

Exit Code

. (Exit code

132

usually means illegal instruction/AVX2;

139

means Segfault). Recommended Next Steps 1. Verify AVX2: Ensure your AKS VM size supports AVX2. 2. Check Identity: Verify why pod

-cn-3

thinks it is

-cn-28

. Check your

cn.conf

or the environment variables in your Deployment/StatefulSet manifest (specifically

HOSTNAME

or

STARROCKS_HOSTNAME

). 3. Inspect Dmesg: If you have access to the AKS node, run

dmesg | grep starrocks

to see if the kernel is reporting a segmentation fault or an illegal instruction. 4. Try a Stable Version: If you are testing, try rolling back to the latest stable 3.x image to see if the behavior persists on your current hardware. References • faq/shared_data_faq.md • quick_start/shared-data.md • deployment/deploy_manually.md • deployment/shared_data/s3.md