@Rocky how do i fix this issue deploying the starrocks/cn-ubuntu:4.1.0-rc01 with the operator? this only affects the cn

[Tue Mar 10 16:47:45 EDT 2026] Process conf file cn.conf ...
│ [Tue Mar 10 16:47:45 EDT 2026] Add myself (kube-starrocks-cn-0.kube-starrocks-cn-search.datalake.svc.cluster.local:9050) into FE ...
│ [Tue Mar 10 16:47:46 EDT 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

Hi there! I'm Rocky. Dealing with a segmentation fault (core dump) right at startup for a Compute Node (CN) can be frustrating. Based on the error log you provided, specifically the segmentation fault occurring during the execution of

start_cn.sh

, this is almost always related to an incompatibility between the StarRocks binary and the host's CPU instruction set or the container environment. Here are the most common causes and how to fix them: 1. Missing AVX2 Support (Most Likely) StarRocks BE and CN binaries are heavily optimized and, by default, require the AVX2 instruction set. If your Kubernetes nodes are running on older hardware or virtual machines that don't expose AVX2, the process will crash immediately with a segmentation fault. * How to check: Run the following command on the Kubernetes node where the CN pod is failing:

bash
    grep avx2 /proc/cpuinfo

* Fix: If you don't see any output, your CPU does not support AVX2. You will need to use a machine that supports it or look for a "no-avx2" specific image (though these are less common for RC releases). 2. Experimental Version (4.1.0-rc01) You are using

4.1.0-rc01

, which is a Release Candidate and may contain experimental code or have different library requirements than stable versions. * Fix: Try switching to a stable version like

4.0.3

or

3.3.x

to see if the issue persists. If the stable version works, it's likely a bug or a specific change in the 4.1.0 RC image. 3. CPU Architecture Mismatch (ARM vs. x86) If you are deploying on an ARM64 environment (like AWS Graviton or Apple Silicon), but using an x86_64 image (or vice-versa), you might encounter a segmentation fault. * Fix: Ensure the image architecture matches your nodes. StarRocks provides specific images for ARM64 if needed. 4. Resource Limits Sometimes, if the

limits

in your StarRocks Operator YAML are too restrictive (especially memory), the CN might fail to initialize its memory pools and crash. * Check: Verify your

StarRocksCluster

spec for CN:

yaml
    starRocksCnSpec:
      requests:
        memory: "8Gi"  # Recommended minimum
        cpu: "4"
      limits:
        memory: "8Gi"
        cpu: "4"

5. Host Kernel Version Newer Ubuntu-based images (like the one you're using) may require a relatively modern Linux kernel (usually 4.18+ or even 5.x). If your host OS is very old (e.g., CentOS 7 with a 3.10 kernel), the Ubuntu-based container might struggle with syscall compatibility. Next Steps for Debugging If the AVX2 check passes, try to get more detail from the pod: 1. Check `be.out`: Even if it segfaults, sometimes the standard output catches a clue.

bash
    kubectl logs <cn-pod-name>

2. Inspect the binary: If you can get a shell in the pod (or use an ephemeral debug container), try running

ldd

on the binary to see if any libraries are missing:

bash
    ldd /opt/starrocks/be/lib/starrocks_be

If you find that your hardware supports AVX2 and the stable version also fails, please let me know your host OS and CPU architecture! References • developers/build-starrocks/build_starrocks_on_ubuntu.md • deployment/environment_configurations.md • developers/mac-compile-run-test.md • deployment/deploy_manually.md • release_notes/release-4.0.md • developers/build-starrocks/Build_in_docker.md