'Official' docker container for LMS?

[adhawkins]

Thanks for that info. In that case it should be relatively simple. Just need a mechanism that queries for the latest nightly when the container is built and installs it.

Will try to find time to have a play.

Andy

[mherger]

'Official' docker container for LMS?

> Thanks for that info. In that case it should be relatively simple. Just
> need a mechanism that queries for the latest nightly when the container
> is built and installs it.

In order to update you'd have to re-build the container? Or can it
update itself?


--

Michael

[rkrug]

'Official' docker container for LMS?

Just an idea - if you put the actual installation of LMS into a mapped directory, the updates could be done independent of the container.

> On 24 Mar 2020, at 14:04, Michael Herger <slim (AT) herger (DOT) net> wrote:
>
>> Thanks for that info. In that case it should be relatively simple. Just
>> need a mechanism that queries for the latest nightly when the container
>> is built and installs it.
>
> In order to update you'd have to re-build the container? Or can it update itself?
>
>
> --
>
> Michael
>

[epoch1970]

In order to update you'd have to re-build the container? Or can it
update itself?

It could, but that's "holding it wrong".
In principle, an image is used to spawn a container, then you kill it or clone it, and the next container will be completely identical except for a few details like hostname, network parameters, etc.
It is possible to commit live modifications made to a container to a new image, but the expected method would rather be to pull (from Docker Hub) a new image that is updated before launching the container:

When using tags, you can docker pull an image again to make sure you have the most up-to-date version of that image. For example, docker pull ubuntu:14.04 pulls the latest version of the Ubuntu 14.04 image.

[mherger]

'Official' docker container for LMS?

>> In order to update you'd have to re-build the container? Or can it
>> update itself?
> It could, but that's "holding it wrong".
> In principle, an image is used to spawn a container, then you kill it or
> clone it, and the next container will be completely identical except for
> a few details like hostname, network parameters, etc.

Are you saying that the image should be re-built regularly like other
builds? The user would, instead of updating LMS in the container, update
the container itself?

--

Michael

[epoch1970]

Yes.
(and the container/image would grow too fast anyway, the fs being layered )

[adhawkins]

That's what I'm planning to do, have LMS itself inside the container image. The config / music / logs / database etc. would be outside, passed into the container as volumes.

Ideally Michael's nightly build process would rebuild the container after it has rebuilt the debs, and push the new container image with an appropriate tag up to Docker's registry.

Managed to get a container to spin up and run LMS so far, so making some progress.

Andy

[epoch1970]

Right.
So the auto-updater could show on the interface a message that a new version is available, but should not try to DL it.

I guess the start-up script could be rigged to make a check/pull before start --or not... my own LMS wasn't built yesterday

Also, we're talking Docker but systemd has (as usual) its nose into containers now, so I guess the scripts/containers should be actionnable via systemd-nspawnd or whatever the name is. No idea what this thing is, personally.

[adhawkins]

Ok, I thought LMS was running, but turns out it's not:

2020-03-25 11:01:44 squeezeboxserver_safe started.
2020-03-25 11:01:49 Logitech Media Server died. Restarting.
2020-03-25 11:01:54 Logitech Media Server died. Restarting.

I'm starting the server with:

ENTRYPOINT ["su", "squeezeboxserver", "-s", "/bin/bash", "-c", "/usr/sbin/squeezeboxserver_safe --background --make-pidfile -- /usr/sbin/squeezeboxserver --prefsdir /var/lib/squeezeboxserver/prefs --logdir /var/log/squeezeboxserver/ --cachedir /var/lib/squeezeboxserver/cache --charset=utf8 --debug server=DEBUG"]

However, I'm not getting any extra debugging info in /var/log/squeezeboxserver/server.log. Can someone advise what command line I need to use to get more logging regarding why it's failing to start?

Cheers

Andy

[epoch1970]

Don't run squeezeboxserver_safe, that shell script only spawns the squeezebox server binary and checks for its health:
- it requires an environment that might not be available (shell env or init.d, I don't remember)
- trying to restart inside the container is the wrong idea; it supposes there is an init process in the container, which is not always -should never be, for the purist- there. Docker (or compose) can be used to specify health checking and remedy procedures.

Run directly "/usr/sbin/squeezeboxserver" like justifiably does.

EDIT. FWIW, this is roughly what I do to launch a container instance. "ubu-lms:local" is a poorly crafted ubuntu-based LMS image:

do_lms_start(){ # server start
	docker rm $(docker ps -a -q --filter name=lms) >/dev/null 2>&1
	docker run -d -p 9000:9000 \
	--network ${bridge} --name lms --hostname lms \
	--entrypoint "/usr/sbin/squeezeboxserver" \
	ubu-lms:local \
	--prefsdir /var/lib/squeezeboxserver/prefs \
	--logdir /var/log/squeezeboxserver/ \
	--cachedir /var/lib/squeezeboxserver/cache \
	--charset=utf8 2>/dev/null || exit 1
}

[adhawkins]

Thanks for that.

Now running this startup script:

#!/bin/sh

/usr/sbin/squeezeboxserver --user squeezeboxserver --prefsdir /var/lib/squeezeboxserver/prefs --logdir /var/log/squeezeboxserver/ --cachedir /var/lib/squeezeboxserver/cache --charset=utf8 --debug server=DEBUG

and getting this:

root@9d03fca9f0b5:/# /lms-startup.sh
Your locale was detected as C, you may have problems with non-Latin filenames.  Consider changing your LANG variable to the correct locale, i.e. en_US.utf8
dirsFor: Didn't find a match request: [scprefs]
[20-03-25 11:46:45.2969] main::init (387) Starting Logitech Media Server (v7.9.3, 1584993250, Tue Mar 24 04:13:22 CET 2020) perl 5.028001 - x86_64-linux-gnu-thread-multi
dirsFor: Didn't find a match request: [videos]
dirsFor: Didn't find a match request: [pictures]
[20-03-25 11:46:45.3038] main::init (417) OS Specific init...
[20-03-25 11:46:45.3041] main::init (464) Server settings effective user and group if requested...
[20-03-25 11:46:45.3045] main::changeEffectiveUserAndGroup (1075) Running as uid: 101 / gid: 65534 65534
[20-03-25 11:46:45.3074] main::init (481) Server binary search path init...
[20-03-25 11:46:45.3078] main::init (485) Server PluginManager init...
[20-03-25 11:46:45.3665] main::init (488) Server strings init...
[20-03-25 11:46:45.3683] Slim::Utils::Strings::loadStrings (125) Retrieving string data from string cache: /var/lib/squeezeboxserver/cache/stringcache.x86_64-linux.bin
[20-03-25 11:46:45.3710] main::init (500) Server SQL init (Slim::Utils::SQLiteHelper)...
[20-03-25 11:46:45.3714] main::init (504) Async DNS init...
[20-03-25 11:46:45.3718] main::init (507) Async HTTP init...
[20-03-25 11:46:45.3722] main::init (512) SqueezeNetwork Init...
[20-03-25 11:46:45.3779] main::init (517) Download repositories init...
[20-03-25 11:46:45.3783] main::init (520) Firmware init...
[20-03-25 11:46:45.3789] main::init (523) Server Info init...
[20-03-25 11:46:45.4416] main::init (526) Server IR init...
[20-03-25 11:46:45.4467] main::init (529) Server Request init...
[20-03-25 11:46:45.4505] main::init (532) Server Queries init...
[20-03-25 11:46:45.4509] main::init (535) Server Buttons init...
[20-03-25 11:46:45.4525] main::init (543) UDP init...
[20-03-25 11:46:45.4533] main::init (546) Slimproto Init...
[20-03-25 11:46:45.4537] main::init (549) Cache init...
[20-03-25 11:46:45.4761] Slim::Utils::SQLiteHelper::postConnect (377) Optimizing DB because of missing or empty sqlite_stat1 table
[20-03-25 11:46:45.4800] Slim::Schema::forceCommit (2143) Warning: Trying to commit transactions before DB is initialized!
[20-03-25 11:46:45.5397] Slim::Utils::SQLiteHelper::postConnect (377) Optimizing DB because of missing or empty sqlite_stat1 table
[20-03-25 11:46:45.5427] Slim::Schema::forceCommit (2143) Warning: Trying to commit transactions before DB is initialized!
[20-03-25 11:46:45.5605] main::init (566) Server HTTP init...
[20-03-25 11:46:45.6005] main::init (570) Source conversion init..
[20-03-25 11:46:45.6060] main::init (576) Server Web Settings init...
[20-03-25 11:46:45.6271] main::init (581) Menu init...
[20-03-25 11:46:45.6281] main::init (592) Server Alarms init...
[20-03-25 11:46:45.6283] main::init (596) Server Load Plugins...
[20-03-25 11:46:45.7879] Slim::Utils::SQLiteHelper::postConnect (377) Optimizing DB because of missing or empty sqlite_stat1 table
[20-03-25 11:46:45.7908] Slim::Schema::forceCommit (2143) Warning: Trying to commit transactions before DB is initialized!
[20-03-25 11:46:45.8411] main::init (599) Server Jive init...
Can't call method "log" on an undefined value at /usr/share/squeezeboxserver/CPAN/Log/Log4perl/Appender.pm line 189.
Can't call method "log" on an undefined value at /usr/share/squeezeboxserver/CPAN/Log/Log4perl/Appender.pm line 189.

server.log contains the same if not similar, other than the last two lines.

I assume it's exiting because of the last two lines in the output of running the startup script. Any thoughts why?

Thanks

Andy

[epoch1970]

I think I've seen this kind of thing but I can't recall anything clearly.
Would you try running your image w/ something like "docker run -ti --rm --entrypoint /bin/bash image-name" to get a shell and keyboard, and then manually run the command? Perhaps you could see what's wrong more easily as the [s]process.[/s] [container will stay running.]
(I assume you want to override the entrypoint your image has set. Otherwise "docker run -ti --rm image-name bash" should work.)

[adhawkins]

That's exactly what I've done. I've overridden the entrypoint in my docker-compose file to just be 'bash', and then used docker-exec to connect to the container and run the script manually.

That's the output I posted.

Andy

[epoch1970]

Ah yes, I missed the 1st line, sorry.
Mhh. https://forums.slimdevices.com/showt...r-reboot/page3
Rights ok on directories, log file exists?

[adhawkins]

Looks like the log files are owned by root:root, and permissions are 644. Could this be because they're being created by the server process before it then 'becomes' the squeezeboxserver user, and then is unable to write? I've tried clearing out the directory, and it's definitely the squeezebox process that's creating the files with these permissions.

root@9d03fca9f0b5:/var/log/squeezeboxserver# ls -al /var/log/squeezeboxserver/
total 28
drwxr-xr-x 1 squeezeboxserver nogroup  4096 Mar 25 11:39 .
drwxr-xr-x 1 root             root     4096 Mar 25 11:35 ..
-rw-r--r-- 1 root             root        0 Mar 25 11:39 perfmon.log
-rw-r--r-- 1 root             root    18728 Mar 25 11:46 server.log

Any 'squeezebox' way to fix this?

Andy