ace's lidarr is not a plain lidarr. HAL mounts custom-cont-init.d and
custom-services.d, and the operator's arr-scripts run from them: an init
script installs beets/deemix/SMA on every start, and eight services
(Audio, AutoConfig, QueueCleaner, ARLChecker, ...) run beside lidarr and
are working today. The catalogue mounted neither, so a take would have
silently stopped all of it. Both are now pathless directories mounted at
the linuxserver image's own paths, root-owned 0755 as the image expects;
empty on a new machine, which the image skips.
The config dir is a pathless ${dir:config} instead of /services/lidarr/config,
the route binding lives in a placed state dir, and /var/lib/mesh/lidarr
keeps only the broker secret.
The image is pinned to the digest ace runs (3.1.0.4875-ls41, sha256:8ab0fd...).
The previous pin was ls40 - older than the data it would open.
Based on feat/servarr-api-provision (#156), which makes lidarr provide
lidarr-api; this branch contains it.
Verified: mesh-controller catalogue tests with MESH_CATALOGUE pointed here
pass (parse + mounts, not skipped); a resolve of route-adapter+lidarr on a
fake ace renders every ${dir:} and ${port:}; the pinned image in a
throwaway container ran a root-owned custom-cont-init.d script and started
a custom-services.d service, answered /ping, the UI and /api/v1/system/status
(200 with its key, 401 without), and re-owned a 1001:2000 file in /config to
PUID. With PUID 1000 it cannot write a 1001:2000 0775 library - the reason
ace needs hq 153 before a take.
jschoubben
cd5688ac3f