(Bug report) ERR_SOCKET_BAD_PORT - port set to NaN on server start

[JM-Atkinson]

Trilium Version

0.55.1

What operating system are you using?

Ubuntu

What is your setup?

Local + server sync

Operating System Version

Linux instance-20220813-1544 5.15.0-1017-oracle #22~20.04.1-Ubuntu SMP Wed Aug 24 11:13:15 UTC 2022 aarch64 aarch64 aarch64 GNU/Linux

Description

I run Trilium on an Ubuntu box through Kubernetes with manually defined manifests (not Helm). This box is ARM64. Today I tried to upgrade from v0.50.1 to v0.55.1.

When starting the server on version v0.55.1, the server starts up with port NaN, despite the port being clearly defined in the config.ini file. I downgraded to v0.54.3, and it works as intended. Something about v0.55.1 is breaking it's ability to successfully get the port from my config.ini.

Container log snippet:

[sigaloid]

This part of the diff between 0.54.3 and 0.55.1 looks relevant:

Though I don't see a change in how it handled the config parsing.

[zadam]

Hi, I don't think there's a regression, but I noticed a small behavior change - in 0.54.X and earlier, if there was an invalid value passed to TRILIUM_PORT env. variable, it got ignored and the one in config.ini was used. In 0.55 wrong value in TRILIUM_PORT will result in the error you posted. Perhaps that is the problem? Do you have TRILIUM_PORT set up?

[JM-Atkinson]

Hi Zadam, upon investigation this is indeed the issue. As per the Kubernetes documentation, Kubernetes sets an environment variable for all service information in the namespace which includes addresses and, importantly, ports for all other services for discovery purposes. These env variables take the name of the deployment, which I naturally called trilium, so as a result it has created the env variable: TRILIUM_PORT=tcp://10.43.211.46:8080. For some reason, the port variable includes the whole address, which is presumably causing the NaN result on start.

I tested setting the env in the manifest to see if it would override it:

env:
    - name: TRILIUM_PORT
      value: "8080"

Which it did: TRILIUM_PORT=8080

And this has resolved the issue:

Thanks for your help pointing that out. I suppose the lesson is that if you are using Kubernetes and set your deployment name to just trilium, you will have a namespace collision with Kubernetes - so best to either not name your deployment trilium, or ensure you set the variable in the manifest to override the Kubernetes one. Could be worth pointing out on the Kubernetes wiki page perhaps.

Thanks again.

[Skaronator]

Thanks to both of you. I noticed the same issue but wasn't able to figure it out since I didn't have that much time to debug it. Setting the env variable directly fixed it for me. I totally forgot that Kubernetes injects a lot of environment variables for service discovery, so yes, that makes sense why Trilium stopped working and posted that weird error in the log.

Thanks again :)