15 minutes to start-up on raspberry pi (with arm32 image)

[srd424]

---

Expected Behavior

App to start-up in a reasonable time - I appreciate it will not be as fast as on x86, but the old docker-booksonic container was nowhere near this slow! (Started in about 30 secs)

Current Behavior

It takes 6 minutes for booksonic just to emit its logo and version number in the logs, and 15 minutes in total to fully start up.

Steps to Reproduce

Install and run with podman on a RPi 3B running Raspbian I have switched to a high-end PSU and verified that the CPU on the RPi is not throttling, but problem persists.

Environment

OS: Raspbian GNU/Linux 10 (buster) CPU architecture: arm32 [armv7l] How docker service was installed: podman 3.4.2 installed from the documented repository on download.opensuse.org

Command used to create docker container (run/create/compose/screenshot)

/usr/bin/podman run --conmon-pidfile %t/container-booksonic-air.pid --cidfile %t/container-booksonic-air.ctr-id --cgroups=no-conmon -d --name=booksonic-air -e PUID=1000 -e PGID=10000 -e TZ=Europe/London -e CONTEXT_PATH=booksonic -p 8080:4040 -v /config/booksonic-air:/config -v /vol/media:/vol/media -v /vol/media-audio:/vol/media-audio linuxserver/booksonic-air

Docker logs

Key section showing the delay here, will upload full logs separately (when app start-up finally completes!)

2022-06-02T21:58:41.515795441+01:00 [services.d] starting services
2022-06-02T21:58:41.536349643+01:00 [services.d] done.
2022-06-02T22:04:29.277806067+01:00   ____              _                    _      
2022-06-02T22:04:29.277806067+01:00  | __ )  ___   ___ | | _____  ___  _ __ (_) ___ 
2022-06-02T22:04:29.277806067+01:00  |  _ \ / _ \ / _ \| |/ / __|/ _ \| '_ \| |/ __|
2022-06-02T22:04:29.277806067+01:00  | |_) | (_) | (_) |   <\__ \ (_) | | | | | (__ 
2022-06-02T22:04:29.277806067+01:00  |____/ \___/ \___/|_|\_\___/\___/|_| |_|_|\___|
2022-06-02T22:04:29.277806067+01:00                                                 
2022-06-02T22:04:29.277806067+01:00                           2201.1.0

log.txt

[srd424]

Possibly https://github.com/linuxserver/docker-booksonic-air/issues/5 was related?

[srd424]

https://github.com/airsonic/airsonic/issues/283 and https://github.com/linuxserver-archive/docker-airsonic-armhf/issues/2 also look very likely related - seems like a newer JDK is the solution, but I appreciate that is a substantial change. Would it be possible to do it for armhf only, to avoid disrupting x86 - if armhf is currently basically unusable it could only improve things?

[srd424]

We seem to be getting the non-JIT version of the JRE, which may well not be helping:

# podman exec -it  booksonic-air java -version
openjdk version "1.8.0_322"
OpenJDK Runtime Environment (IcedTea 3.22.0) (Alpine 8.322.06-r0)
OpenJDK Zero VM (build 25.322-b06, interpreted mode)

The original 'booksonic' container shows:

# podman exec -it  booksonic java -version
openjdk version "1.8.0_312"
OpenJDK Runtime Environment (build 1.8.0_312-8u312-b07-0ubuntu1~18.04-b07)
OpenJDK Client VM (build 25.312-b07, mixed mode)

So this could indeed be the problem.

[srd424]

Reverting to v2201.1.0-ls53, which was the last version based on Ubuntu, and uses the Hotspot JVM, starts in 2m20s. Not great but an awful lot better than 15min! Would it be reasonable to revert just armhf to the Ubuntu base image? I will look tomorrow and see if I can figure out why alpine doesn't build its jre with hotspot enabled.

[srd424]

https://git.alpinelinux.org/aports/commit/community/openjdk8?id=2ef23635a7f6cbdb54c363a3970362879e28e7f4 may be the commit that disables hotspot on alpine armhf, but it's not entirely clear.

[srd424]

Java 11 doesn't seem to make a speed difference, and Java 18 causes all sorts of crashes, so it doesn't look like changing JRE version per se will help, just enabling Hotspot. Roll back to the Ubuntu version for armhf might be simplest if that doesn't contradict any linuxserver policies?

[srd424]

Per https://github.com/linuxserver/docker-booksonic-air/pull/12#issuecomment-1147593596, armhf support is being deprecated, and it seems the alpine aarch64 JRE packages are built with the Hotspot VM enabled, so dropping armhf may be the obvious solution here now the RPi has stable 64bit support (at least on the higher performance models likely to be used for a home server, anyway.)

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[drizuid]

We no longer support 32 bit arm, I believe that eliminates this as an issue, but I am pending a reply on this.

[srd424]

I'm pretty sure it does, yes, though it's been ages since I looked at this and can't remember the details. (AFAICR I've migrated my own stuff either to arm64 or away from booksonic entirely anyway.) I will close.