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?