Docker - slow startup on systems with spinning disks results in stuck deployment on Kubernetes chart

[zappallot]

I run the LMS with the Kubernetes chart form Truecharts on my Truenas SCALE NAS with two spinning disks.

The chown command in the start-container.sh script takes around 10 minutes to complete. In particular, it is the /lms folder that takes that long.

This results in a "stuck deployment" in the above mentioned chart, because the chown command takes longer than the configured startupProbe settings:
Startup: tcp-socket :9000 delay=10s timeout=2s period=5s #success=1 #failure=60

Could this be solved by moving the chown also to the Dockerfile, like done with the /config and /playlist folders?
RUN mkdir -p /config /music /playlist /lms && chown -R squeezeboxserver:nogroup /config /playlist
the /lms folder is copied after that statement.

Is it then still necessary to run the chown inside the startup script?

Another solution would be to make the startupProbe configurable in the Truecharts chart, but that is only necessary if the command above could not be made faster.

Thanks for the work that is still put into the LMS!

[mherger]

I believe that if a chmod on /lms takes that long, then there's a problem with your system or configuration. A few seconds? Yes. But minutes? No way. There are users of this image running it in Docker on rather cheap or moderate NAS devices, or even Raspberry Pis.

Did you check your log files for hints about file system issues?

[zappallot]

Hi, thanks for looking into this.
the NAS is running TrueNAS Scale, which uses ZFS as a file system. Looks like the low performance might is coming from that.
The system is preconfigured from iXSystems, so the configuration should be alright.

Although I can understand that the reaction might be to just close this thread and point to ZFS, I'd love to know if my idea above would work to improve the initial startup time and maybe even solve the problem for some ZFS users out there.

Btw, I got the LMS running by increasing the wait time for the first startup manually, so the software runs fine after the initial start. But this is only a temp. solution, because that wait time would get on reset again on the next config change.

[dustinsterk]

I am having the same issue (also on TrueNAS Scale/ZFS) and following this thread to increase the statup time to 600s worked and it starts literally at the 9min 58s mark: https://www.truenas.com/community/threads/logitech-media-server-stuck-in-deployment-scale-22-12-2.110198/

Is there any other workaround or idea why this takes so long? It seems like something else internally is blocking as a simple chown should be almost immediate.

[dustinsterk]

I gave up on this and just created a new VM with a bridged nic to the TrueNAS host....works like a charm but you have to access your Volume data via SMB. Hopefully this can eventually be fixed down the road as I would love to use a docker container. Thanks!