[GH-ISSUE #717] Invalid digit found in string in KOMODO_PORT #7460

New Issue

GiteaMirror · 2026-04-27T21:09:59-05:00

GiteaMirror commented

2026-04-27 21:09:59 -05:00

Originally created by @JavertArdo on GitHub (Aug 7, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/717

The problem appears when deploying Komodo Core in Kubernetes. When not specifying directly KOMODO_PORT value (which should be 9120 by default), Pod crashes with following error:

kubectl get pods -A
NAMESPACE        NAME                                       READY   STATUS    RESTARTS         AGE
app-komodo       komodo-f964fbff9-97pmk                     0/1     Error     1 (3s ago)       12s

kubectl logs komodo-f964fbff9-97pmk -n app-komodo

thread 'tokio-runtime-worker' panicked at bin/core/src/config.rs:24:11:
Error {
    context: "failed to parse core Env",
    source: Custom(
        "invalid digit found in string while parsing value 'tcp://10.101.108.109:9120' provided by KOMODO_PORT",
    ),
}
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: task 5 panicked with message "Error {\n    context: \"failed to parse core Env\",\n    source: Custom(\n        \"invalid digit found in string while parsing value 'tcp://10.101.108.109:9120' provided by KOMODO_PORT\",\n    ),\n}"

Here is the configuration:

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: komodo-core
  namespace: app-komodo
stringData:
  KOMODO_JWT_SECRET: "yoursecret"
  KOMODO_PASSKEY: "yoursecret"
---
apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: komodo-database
  namespace: app-komodo
stringData:
  KOMODO_DATABASE_ADDRESS: "yourip:27017"
  KOMODO_DATABASE_USERNAME: "mongo"
  KOMODO_DATABASE_PASSWORD: "password"

apiVersion: apps/v1
kind: Deployment
metadata:
  name: komodo
  namespace: app-komodo
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: komodo
  template:
    metadata:
      labels:
        app.kubernetes.io/name: komodo
    spec:
      containers:
      - name: core
        image: ghcr.io/moghtech/komodo-core:1.18.4
        ports:
        - name: http
          containerPort: 9120
        env:
        - name: KOMODO_LOCAL_AUTH
          value: "true"
        - name: KOMODO_DISABLE_USER_REGISTRATION
          value: "false"
        - name: KOMODO_OIDC_ENABLED
          value: "false"
        envFrom:
        - secretRef:
            name: komodo-core
        - secretRef:
            name: komodo-database
        volumeMounts:
        - name: komodo-cache
          mountPath: /repo-cache

      volumes:
      - name: komodo-cache
        persistentVolumeClaim:
          claimName: komodo-cache

The workaround is to explicitly define or somehow override KOMODO_PORT to 9120.

...
        env:
...
        - name: KOMODO_PORT
          value: "9120"
...

kubectl get pods -A
NAMESPACE        NAME                                       READY   STATUS    RESTARTS         AGE
app-komodo       komodo-7c6659c6b-7p588                     1/1     Running   0                17m

I didn't notice this issue using Podman Compose when not specifying the KOMODO_PORT. If I understand the error correctly, instead of having only the number in KOMODO_PORT the application appended prefix tcp://10.101.108.109: before parsing value?

Version: komodo-core:1.18.4

Originally created by @JavertArdo on GitHub (Aug 7, 2025). Original GitHub issue: https://github.com/moghtech/komodo/issues/717 The problem appears when deploying Komodo Core in Kubernetes. When not specifying directly `KOMODO_PORT` value (which should be 9120 by default), Pod crashes with following error: ```shell kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE app-komodo komodo-f964fbff9-97pmk 0/1 Error 1 (3s ago) 12s ``` ```shell kubectl logs komodo-f964fbff9-97pmk -n app-komodo thread 'tokio-runtime-worker' panicked at bin/core/src/config.rs:24:11: Error { context: "failed to parse core Env", source: Custom( "invalid digit found in string while parsing value 'tcp://10.101.108.109:9120' provided by KOMODO_PORT", ), } note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Error: task 5 panicked with message "Error {\n context: \"failed to parse core Env\",\n source: Custom(\n \"invalid digit found in string while parsing value 'tcp://10.101.108.109:9120' provided by KOMODO_PORT\",\n ),\n}" ``` Here is the configuration: ```yaml apiVersion: v1 kind: Secret type: Opaque metadata: name: komodo-core namespace: app-komodo stringData: KOMODO_JWT_SECRET: "yoursecret" KOMODO_PASSKEY: "yoursecret" --- apiVersion: v1 kind: Secret type: Opaque metadata: name: komodo-database namespace: app-komodo stringData: KOMODO_DATABASE_ADDRESS: "yourip:27017" KOMODO_DATABASE_USERNAME: "mongo" KOMODO_DATABASE_PASSWORD: "password" ``` ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: komodo namespace: app-komodo spec: replicas: 1 selector: matchLabels: app.kubernetes.io/name: komodo template: metadata: labels: app.kubernetes.io/name: komodo spec: containers: - name: core image: ghcr.io/moghtech/komodo-core:1.18.4 ports: - name: http containerPort: 9120 env: - name: KOMODO_LOCAL_AUTH value: "true" - name: KOMODO_DISABLE_USER_REGISTRATION value: "false" - name: KOMODO_OIDC_ENABLED value: "false" envFrom: - secretRef: name: komodo-core - secretRef: name: komodo-database volumeMounts: - name: komodo-cache mountPath: /repo-cache volumes: - name: komodo-cache persistentVolumeClaim: claimName: komodo-cache ``` The workaround is to explicitly define or somehow override `KOMODO_PORT` to 9120. ```yaml ... env: ... - name: KOMODO_PORT value: "9120" ... ``` ```yaml kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE app-komodo komodo-7c6659c6b-7p588 1/1 Running 0 17m ``` I didn't notice this issue using Podman Compose when not specifying the `KOMODO_PORT`. If I understand the error correctly, instead of having only the number in `KOMODO_PORT` the application appended prefix `tcp://10.101.108.109:` before parsing value? Version: komodo-core:1.18.4

GiteaMirror added the seen 👀 label 2026-04-27 21:09:59 -05:00

GiteaMirror closed this issue

2026-04-27 21:10:00 -05:00

GiteaMirror commented

2026-04-27 21:10:02 -05:00

@mbecker20 commented on GitHub (Aug 19, 2025):

I'm not sure where that Komodo port value is coming from, I don't see where it would be, unless you also give it a config file with this value

@mbecker20 commented on GitHub (Aug 19, 2025): I'm not sure where that Komodo port value is coming from, I don't see where it would be, unless you also give it a config file with this value

GiteaMirror commented

2026-04-27 21:10:04 -05:00

@JavertArdo commented on GitHub (Aug 20, 2025):

After digging a little bit I might have some suspicion that this value comes from different environment variable.

When we log into pod (the working one after applying workaround, since the previous is crashing while parsing config values) shell and print all mounted environment variables, I see some of them are auto mounted by Kubernetes.

$ kubectl get pods -A

NAMESPACE        NAME                                       READY   STATUS    RESTARTS       AGE
app-komodo       komodo-7c6659c6b-7p588                     1/1     Running   0              13d

$ kubectl exec -it -n app-komodo pod/komodo-7c6659c6b-7p588 -- /bin/sh

$ env | grep KOMODO_PORT

KOMODO_PORT_9120_TCP_PORT=9120
KOMODO_PORT_9120_TCP_PROTO=tcp
KOMODO_PORT=9120
KOMODO_PORT_9120_TCP=tcp://10.102.138.69:9120
KOMODO_PORT_9120_TCP_ADDR=10.102.138.69

apiVersion: v1
kind: Service
metadata:
  name: komodo
  namespace: app-komodo
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: komodo
  ports:
  - protocol: TCP
    port: 9120
    targetPort: 9120

And the format seems to be:

{SERVICE_NAME}_PORT_{PORT_VALUE}_{PROTOCOL}

As we can see four of them are auto created by Kubernetes for Service defined for this Pod.

So, is it possible that Komodo is trying to get any env starting with KOMODO_PORT. Since in faulty scenario KOMODO_PORT is not explicitly defined we should have only four of them in Pod. So, Komodo get the shortest matching env starting with KOMODO_PORT? Which is KOMODO_PORT_9120_TCP and then parsing failed, since the value was not a digit.

I believe Podman does not automount such env vars in container. Hence, the issue is observed only in Kubernetes in the same configuration.

@JavertArdo commented on GitHub (Aug 20, 2025): After digging a little bit I might have some suspicion that this value comes from different environment variable. When we log into pod (the working one after applying workaround, since the previous is crashing while parsing config values) shell and print all mounted environment variables, I see some of them are auto mounted by Kubernetes. ```shell $ kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE app-komodo komodo-7c6659c6b-7p588 1/1 Running 0 13d ``` ```shell $ kubectl exec -it -n app-komodo pod/komodo-7c6659c6b-7p588 -- /bin/sh ``` ```shell $ env | grep KOMODO_PORT KOMODO_PORT_9120_TCP_PORT=9120 KOMODO_PORT_9120_TCP_PROTO=tcp KOMODO_PORT=9120 KOMODO_PORT_9120_TCP=tcp://10.102.138.69:9120 KOMODO_PORT_9120_TCP_ADDR=10.102.138.69 ``` ```yaml apiVersion: v1 kind: Service metadata: name: komodo namespace: app-komodo spec: type: ClusterIP selector: app.kubernetes.io/name: komodo ports: - protocol: TCP port: 9120 targetPort: 9120 ``` And the format seems to be: ``` {SERVICE_NAME}_PORT_{PORT_VALUE}_{PROTOCOL} ``` As we can see four of them are auto created by Kubernetes for Service defined for this Pod. So, is it possible that Komodo is trying to get any env starting with `KOMODO_PORT`. Since in faulty scenario `KOMODO_PORT` is not explicitly defined we should have only four of them in Pod. So, Komodo get the shortest matching env starting with `KOMODO_PORT`? Which is `KOMODO_PORT_9120_TCP` and then parsing failed, since the value was not a digit. I believe Podman does not automount such env vars in container. Hence, the issue is observed only in Kubernetes in the same configuration.

GiteaMirror commented

2026-04-27 21:10:07 -05:00

@mbecker20 commented on GitHub (Aug 30, 2025):

I don't believe Komodo will parse KOMODO_PORT from any other variable other than KOMODO_PORT exactly. For example, I cannot reproduce this through passing KOMODO_PORT_9120_TCP on the environment.
I am closing this issue as its kind of out of scope, but if you have any other comments I will see it.

@mbecker20 commented on GitHub (Aug 30, 2025): I don't believe Komodo will parse `KOMODO_PORT` from any other variable other than `KOMODO_PORT` exactly. For example, I cannot reproduce this through passing `KOMODO_PORT_9120_TCP` on the environment. I am closing this issue as its kind of out of scope, but if you have any other comments I will see it.

GiteaMirror commented

2026-04-27 21:10:09 -05:00

@JavertArdo commented on GitHub (Aug 30, 2025):

Just to leave a comment for others. I agree with you that it is not Komodo issue, it is a Kubernetes way of env variables injection into Pods. The problem is due to naming collision of Komodo variables and created Kubernetes Service. I deployed some other app to test.

/ # env | grep -i myapp
MYAPP_PORT_3000_TCP=tcp://10.98.73.132:3000
MYAPP_SERVICE_HOST=10.98.73.132
MYAPP_SERVICE_PORT=3000
MYAPP_PORT=tcp://10.98.73.132:3000               <-- Auto created by Kubernetes
MYAPP_PORT_3000_TCP_ADDR=10.98.73.132
MYAPP_PORT_3000_TCP_PORT=3000
MYAPP_PORT_3000_TCP_PROTO=tcp

apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: app-myapp
spec:
  type: ClusterIP
  selector:
    app.kubernetes.io/name: myapp
  ports:
  - protocol: TCP
    port: 3000
    targetPort: 3000

Now I am sure that Kubernetes created KOMODO_PORT with value tcp://10.101.108.109:9120 which caused an error during parsing. When explicitly defined KOMODO_PORT with valid value (which overriden previous one) then there was no issue.

@mbecker20, thank you for taking a look and your time.

@JavertArdo commented on GitHub (Aug 30, 2025): Just to leave a comment for others. I agree with you that it is not Komodo issue, it is a Kubernetes way of env variables injection into Pods. The problem is due to naming collision of Komodo variables and created Kubernetes Service. I deployed some other app to test. ```shell / # env | grep -i myapp MYAPP_PORT_3000_TCP=tcp://10.98.73.132:3000 MYAPP_SERVICE_HOST=10.98.73.132 MYAPP_SERVICE_PORT=3000 MYAPP_PORT=tcp://10.98.73.132:3000 <-- Auto created by Kubernetes MYAPP_PORT_3000_TCP_ADDR=10.98.73.132 MYAPP_PORT_3000_TCP_PORT=3000 MYAPP_PORT_3000_TCP_PROTO=tcp ``` ```yaml apiVersion: v1 kind: Service metadata: name: myapp namespace: app-myapp spec: type: ClusterIP selector: app.kubernetes.io/name: myapp ports: - protocol: TCP port: 3000 targetPort: 3000 ``` Now I am sure that Kubernetes created `KOMODO_PORT` with value `tcp://10.101.108.109:9120` which caused an error during parsing. When explicitly defined `KOMODO_PORT` with valid value (which overriden previous one) then there was no issue. @mbecker20, thank you for taking a look and your time.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/komodo#7460