A more informative error message

[jdownie]

Is your feature request related to a problem? Please describe. I'm attempting to host the nightly docker image in a k3s cluster. I'm setting PUID and GUID to 1000 and using a PV/PVC to mount two volumes; one for /config and one for /data. By overriding entrypoint.sh i've been able to add a sleep statement to the end so that I can keep the container alive long enough explore the environment. I'm finding that I am able to su as stump and then run /app/stump. Unfortunately I get "Failed to initialize Stump core: invalid digit found in string" as an error message. I've confirmed that the stump user has read and write access to /config and /data BTW.

Describe the solution you'd like I'd like some more detailed output. I'm not sure if this "invalid digit" is in a file somewhere, and if so, where?

Describe alternatives you've considered I've emptied the /config path expecting a fresh configuration to be created, which didn't happen.

Additional context N/A

[aaronleopold]

Hey 👋

I'll try and help figure out what might be happening, but I haven't personally used k3s before so that is a gap in my knowledge.

Unfortunately I get "Failed to initialize Stump core: invalid digit found in string" as an error message

This smells like a failure to parse one of the integer values, which probably is happening somewhere before the config would be written (which would also explain your expectation of the config being written when it is not).

My guess would be it is occurring somewhere around here. The trace, in case you're curious, starts about here, with this being the contents of that init_config call. The default config is used first, and then mutated based on any existing config file contents, and then again for environment overrides. The default is fairly idempotent, and unless you provided/wrote a Stump.toml config file I'd suspect something is funky in the environment variables. Are you providing any environment variables to the container that you can share?

I'd like some more detailed output. I'm not sure if this "invalid digit" is in a file somewhere, and if so, where?

I'll add some error level logs to those .map_err calls to provide better context around these kinds of initialization issues. I believe this error is an InvalidConfig error that wraps an InitializationError

[aaronleopold]

FWIW, I just tried spinning up a container but provided a bad port value and got that exact error:

STUMP_PORT="10801f"

stump-cpy-stump-1  | Group gid 12 already exists
stump-cpy-stump-1  | Group name 'man' does not match expected name 'stump'. Using 'man' instead.
stump-cpy-stump-1  | Adding user stump with uid 501
stump-cpy-stump-1  | Adding system user `stump' (UID 501) ...
stump-cpy-stump-1  | Adding new user `stump' (UID 501) with group `man' ...
stump-cpy-stump-1  | Not creating home directory `/home/stump'.
stump-cpy-stump-1  | Setting timezone to America/Phoenix
stump-cpy-stump-1  | Error: InvalidConfig("Failed to initialize Stump core: invalid digit found in string")
stump-cpy-stump-1 exited with code 1

Definitely not intuitive though, the context of why is definitely something I'll add in for those

[jdownie]

Hey, I reckon you've very astutely sniffed out my problem. I jumped back into that container (in my k3s environment) and found STUMP_PORT=tcp://10.43.113.56:30801. On the other hand, my plan 'ol Podman environment has STUMP_PORT=10801. That's really interesting that "something" between my kubernetes service and definitions, the port is being defined with some internal ip address. I've attached env.txt containing all of the environment variables in that k3s container. Thanks for your quick feedback and please let me know how i can help.

[aaronleopold]

I jumped back into that container (in my k3s environment) and found STUMP_PORT=tcp://10.43.113.56:30801

Ha, yeah that will definitely fail to parse as an integer 😅 As for why there is something in your k3s environment causing the port to have an entire ip address, I'm not sure unfortunately. I'm not really familiar enough with k3s to understand what might be happening, but I assume if it were to be corrected (i.e. the STUMP_PORT just having the port and not an ip address) the issue should resolve itself.

I did take a peek at the other vars you have though and, at least wrt Stump, didn't see any other issues. I can check more thoroughly in the morning if updating the port value doesn't fix your issue, though. I just merged a tiny PR that, once it finishes building, should give you those extra logs, as well.

[jdownie]

Oooh, nice. Thanks again.

I might fiddle with my own entrypoint script to strip off everything before that last colon to work around this k3s specific behaviour. Thanks again for your help!

[jdownie]

FWIW, I added thit to the entrypoint script (in my environment) to compensate for this k3s behavior....

echo "STUMP_PORT (Before): $STUMP_PORT"
STUMP_PORT="`echo "$STUMP_PORT" | tr ':' '\n' | tail -n 1`"
echo "STUMP_PORT (After): $STUMP_PORT"

...which gives this in my container's output...

2024-01-01T10:55:32.264392750Z STUMP_PORT (Before): tcp://10.43.86.129:30801
2024-01-01T10:55:32.272538727Z STUMP_PORT (After): 30801

I'll disable this soon to see the error message that you've added. Thanks.

[moyiz]

Passing STUMP_PORT with quoted port number seems to workaround it for me. Here it my deployment.yaml:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: stump
spec:
  selector: null
  template:
    spec:
      containers:
        - name: app
          image: aaronleopold/stump:nightly
          ports:
            - containerPort: 10801
          env:
            - name: STUMP_PORT
              value: "10801"
          envFrom:
            - configMapRef:
                name: media-env
          volumeMounts:
            - mountPath: /config
              name: config
            - mountPath: /data
              name: data
              subPath: media/books
      volumes:
        - name: config
          persistentVolumeClaim:
            claimName: stump-config
        - name: data
          persistentVolumeClaim:
            claimName: media-data-0

[jdownie]

Passing STUMP_PORT with quoted port number seems to workaround it for me. Here it my deployment.yaml:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: stump
spec:
  selector: null
  template:
    spec:
      containers:
        - name: app
          image: aaronleopold/stump:nightly
          ports:
            - containerPort: 10801
          env:
            - name: STUMP_PORT
              value: "10801"
          envFrom:
            - configMapRef:
                name: media-env
          volumeMounts:
            - mountPath: /config
              name: config
            - mountPath: /data
              name: data
              subPath: media/books
      volumes:
        - name: config
          persistentVolumeClaim:
            claimName: stump-config
        - name: data
          persistentVolumeClaim:
            claimName: media-data-0

Wow, I didn't try that.bi assumed that something else would supercede that value. That makes my entrypoint script hack look a bit bloated. Thanks.

[Critical-Impact]

You can also turn off service links in your kubernetes deployment manifest enableServiceLinks: false This stops the conflicting environment variable from being added