跳到主要内容

故障排查

1. http: server gave HTTP response to HTTPS client​

CSGHub 默认安装使用不安全的 registry（即上面提到的：<domain or IPv4>:5000），需要确保 Kubernetes 可以从这个 registry 拉取镜像。因此在 Kubernetes 的每个节点上需做如下配置：

  1. 配置前请确认配置文件 /etc/containerd/config.toml 是否存在，若不存在，可以使用以下命令创建。
mkdir -p /etc/containerd/ && containerd config default >/etc/containerd/config.toml

  1. 配置 config_path

    • Containerd 1.x

      version = 2

      [plugins."io.containerd.grpc.v1.cri".registry]
           config_path = "/etc/containerd/certs.d"

    • Containerd 2.x

       version = 3

       [plugins."io.containerd.cri.v1.images".registry]
            config_path = "/etc/containerd/certs.d"

  2. 配置 hosts.toml

    # 创建 Registry 配置目录
    mkdir /etc/containerd/certs.d/<domain or IPv4>:5000

    # 定义配置
    cat >/etc/containerd/certs.d/<domain or IPv4>:5000/hosts.toml <<EOF
    server = "http://<domain or IPv4>:5000"

    [host."http://<domain or IPv4>:5000"]
       capabilities = ["pull", "resolve", "push"]
       skip_verify = true
       plain-http = true
    EOF

  3. 重启 containerd 服务

    systemctl restart containerd

2. tcp: lookup casdoor.example.com on 10.43.0.10:53: no such host​

此问题是由于集群无法解析域名，如果是公有域名请配置域名解析，如果是自定义域名请配置 CoreDNS 和 Hosts 解析。CoreDNS 解析配置方式如下：

# 添加自定义域名解析
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns-custom
  namespace: kube-system
data:
  example.server: |
    example.com {
      hosts {
        172.25.11.131 csghub.example.com csghub
        172.25.11.131 casdoor.example.com casdoor
        172.25.11.131 registry.example.com registry
        172.25.11.131 minio.example.com minio
        172.25.11.131 temporal.example.com temporal
        172.25.11.131 starship.example.com starship
        172.25.11.131 starship-api.example.com starship-api
      }
    }
EOF

# 更新 coredns pods
$ kubectl -n kube-system rollout restart deploy coredns

3. ssh: connect to host csghub.example.com port 22: Connection refused​

此问题常由于 gitlab-shell job 执行失败导致，出现此问题请按照如下方式进行排查：

  1. 查看

    $ kubectl get cm csghub-ingress-nginx-tcp -n csghub -o yaml
    apiVersion: v1
    data:
      "22": default/csghub-gitlab-shell:22
    ......

    确认 22 端口对应的服务名是否正确。

  2. 如果不正确手动进行修改

    $ kubectl -n csghub edit configmap/csghub-ingress-nginx-tcp
    apiVersion: v1
    data:
      "22": csghub/csghub-gitlab-shell:22

    # 更新 ingress-nginx-controller
    $ kubectl rollout restart deploy csghub-ingress-nginx-controller -n csghub

4. 如何禁用多源同步并清理已经同步的数据​

CSGHub 默认启动会开启多源同步，但是在某些情况下可以能需要禁用多源同步仅做本地模型的托管，因此就需要禁用多源同步并且需要清楚已经同步到本地的多源同步列表数据。具体操作如下：

  • Docker

    • 添加如下配置

      services:
        csghub:
          image: opencsg-registry.cn-beijing.cr.aliyuncs.com/opencsghq/omnibus-csghub:<version>
          environment:
            CSGHUB_OMNIBUS_CONFIG: |
              csghub:
                external_url: "http://csghub.example.com"
              ......
              server:
                multi_sync:
                  enabled: false   # 禁用多源同步
              ......

    • 应用配置

      docker compose up -d

    • 清理多源同步数据

      docker exec -it omnibus-csghub-1 csghub-psql "SELECT cleanup_multi_sync_data();"

  • Helm Chart

    • v1.10.0 以后版本

      helm upgrade --install csghub csghub/csghub \
        ......
        --set csghub.server.multiSync.enabled=false \
        ......

    • v1.10.0 及以前版本

      helm upgrade --install csghub csghub/csghub \
        ......
        --set csghub.server.environments.STARHUB_SERVER_MULTI_SYNC_ENABLED=false \
        ......

    • 清理多源同步数据

      kubectl exec -it pod/csghub-postgresql-0 -n csghub -- su - postgres -lc "psql -d csghub_server -c 'SELECT cleanup_multi_sync_data();'"

5. failed to create pull mirror in mirror server: rpc error: code = PermissionDenied desc = permission denied​

创建镜像仓库失败，排查 Gitaly 令牌是否正确。

6. failed to set rlimit for open files. Try starting as root or requesting smaller maxconns value​

此问题是问题机器的配置或设置不足以支持过多的 loki 连接，尝试减低连接数设置即可，操作如下：

--set loki.chunksCache.connectionLimit=1000 --set loki.resultsCache.connectionLimit=1000

7. database "csghub_dataflow" does not exists​

此问题是因为在 csghub 应用初始化安装的饰扣，postgresql.databases列表中并没有包含数据库csghub_dataflow，手动创建即可：

kubectl exec -it csghub-postgresql-0 -n csghub -- su - postgres -lc 'psql -U csghub'

CREATE DATABASE csghub_dataflow ENCODING UTF8;

等待 Pod 自动重建或者手动快速重建。

kubectl rollout restart sts csghub-dataflow -n csghub

8. After upgrading, refreshing the page prompts 'Unauthorized'.​

请尝试登出后重新登录。

9. XNet 始终处于 Init 0/2 初始化等待状态​

此问题是由于 XNet 服务需要有自己的数据库，但是 postgresql 数据库的创建仅在数据库初始化时有效，因此需要手动创建数据库。

kubectl exec -it csghub-postgresql-0 -n csghub -- su - postgres -lc 'psql -U csghub -d csghub_server'

CREATE DATABASE csghub_xnet OWNER csghub;

10. Failed to allocate directory watch: Too many open files​

此问题是由于操作系统内核参数设置过低导致。通过以下调整后重启 Pod。

# 查看当前内核参数设置
sysctl fs.inotify.max_user_instances

# 修改内核参数
echo "fs.inotify.max_user_instances = 256" >> /etc/sysctl.conf

# 生效内核参数
sysctl -p

重建 Pod 即可。

11. Error checking push permissions -- make sure you entered the correct tag name, and that you are authenticated correctly.​

此问题是由于 Space 无法正常连接到容器镜像仓库，常见原因是更换过 csghub 的访问方式（例如：修改过主域名，修改过服务的类型，NodePort 和 LoadBalancer 的更换），导致默认创建的 docker registry secret 和实际不符合无法完成验证。

此种情况通常由两种解决方案：

方式一：

因为 docker registry secret 是通过 auto configure job 进行创建的，因此修改如下参数可以修改 secret 的更新逻辑。

如果你的版本是v1.12.0及以上，可以通过修改--set runner.kymlMode=update进行修复。

方式二：

任何版本都可以使用此种方式。

kubectl delete secret csghub-docker-credentical -n spaces

然后重新执行 helm upgrade --install 操作。

除此之外如果是 insecure registry 还需要同步修改 containerd 的配置。

12. Failed to upload object: failed to list object parts: The specified key does not exist.​

{"time":"2026-01-15T04:27:35.707998143Z","level":"ERROR","msg":"failed to download and upload lfs file","error":"failed to upload object: failed to list object parts: The specified key does not exist.","workerID":1,"error":"failed to upload object: failed to list object parts: The specified key does not exist.","sourceURL":"https://sync.opencsg.com/models/AIWizards/DeepSeek-R1-Block-INT8.git","repoPath":"CSG_AIWizards/DeepSeek-R1-Block-INT8","repoType":"model","pointer":{"oid":"4bf319deea1abe908bfb1ed8737e2247d6fe6846647443985cfcff5cf6d67457","size":4302380984,"download_url":"https://opencsg-gitea-lfs.oss-cn-beijing.aliyuncs.com/lfs/4b/f3/19deea1abe908bfb1ed8737e2247d6fe6846647443985cfcff5cf6d67457?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=LTAI5tH6mgHpNxCBvEYyu9ov%2F20260115%2Fcn-beijing%2Fs3%2Faws4_request&X-Amz-Date=20260115T042735Z&X-Amz-Expires=259200&X-Amz-SignedHeaders=host&X-Amz-Signature=d0f81d4f3e3366b1fbc4c69082a9849dc1ed41d5730fa87f58115da21cb4d258"}}

此问题是由于 Redis 缓存污染导致多源同步同步 LFS 文件时异常。手动清理下缓存：

redis-cli --scan --pattern 'upload-id*' | xargs -r redis-cli del

or

redis-cli

EVAL "
local cursor = '0'
repeat
  local res = redis.call('SCAN', cursor, 'MATCH', 'upload-id*', 'COUNT', 100)
  cursor = res[1]
  for _, key in ipairs(res[2]) do
    redis.call('DEL', key)
  end
until cursor == '0'
return 'done'
" 0

然后重新同步项目或者点击重试。

13. Failed to upload xorb: inconsistent data: xorbID exists in DB but missing in S3: The specified key does not exist.​

此问题是由于 xnet 元数据信息和对象存储数据不一致导致。

我们将通过 sdk 在后面提供一致性校验和修复方案