In order to preserve your license details you need to configure a mapping for your SongKong configuration to SongKongs /songkong folder, this gives access to SongKongs preferences, logs and reports from outside the Docker otherwise if you remove the docker image then your licensing, logs and preferences information will be lost.
Here we have created a new top level Shared folder called config , and then created a songkong folder within it, the mount path needs to be set to /songkong
It says here that license info etc is saved on the mentioned docker mount. But it is not. When I look in de docker image it is saved to the root homedir in (hidden) subfolder “.songkong”.
Is the instruction wrong or outdated?
Did you look in the Docker mount as well, Im not aware of an issue but Im away from office i cannot check
Hello, yes, if I follow the instructions I would create a mountpoint to a folder /songkong in the docker container but that folder is as yet non-existant and thus empty.
On runtime it seems songkong copies default settings to a location, which seems to be at default a hidden folder .songkong in it’s own homedir. The docker will be running as root (in example), and will thus create the .songkong folder in /root the container.
I have not seen/found anywhere (yet) how to influence that configuration folder.
I presume your idea is to let it be created not in the homedir, but that created /songkong folder…
Alas, that seems not to happen (at least not in my docker instances…)
Not to big an issue: when you know as what user the docker will run (and if you do not change it with --user, that will be root) it is easy enough to modify the mount to the right folders: “{replace-with-homedir}/.songkong”…
But for less proficient docker users an (environment) setting that can be used for modification of the settings folder would probably be a nice to have and understand.
(Also easier to use when the need for moving too big database arises…)
Edit: ok, can not as yet run the docker container as other user it seems. Will need to check that out a bit more… So then the proper mount folder is simply “/root/.songkong”
Edit2: seems the docker has debug logging on as default. Hope it rotates… Interestingly enough it still says the accousticid API key is invalid?
You are right the idea is that settings are stored in /songkong. Sorry I’m away from office until end of week and cannot check my nas Docker instance until then.
No problem. It works.
But maybe nice to have an easy install/config for all.
(Disclaimer Im not a Docker expert) but I looked at this again, and found no issue, after installing SongKong 9.1.1 I still had my license, but I thought maybe there was some more recent bug
So I did the following:
So can cannot see any issue here, but keen to work out why you are having issue
The hidden .songkong folder is used by standard Linux installs but not by Docker images, so I wonder if you are using a custom image based on linux build. Or maybe there is an issue using root user, Im not using root user (actually I’m not clear how to use root user on my docker), I have one power user on my Synology Nas but they are not called root
If it helps the docker build file is https://bitbucket.org/ijabz/songkongdocker/src/master/Dockerfile
Weird. I use the docker hub songkong/songkong:latest, which is the same as yours? But I run in a (up to date debian) native docker with compose. You in synology or unraid? Maybe those configure a different user so it does not install in the homedir maybe?
Installed once on a bare debian/ubuntu linux and songkong also installed its settings in similar homedir folder… The docker image is an alpine os, so see and expect nothing weird there either…
So why the songkong image behaves different is then a mystery to me as well.
Must admit I struggle anyway: getting OOM errors even when setting memory limit on the container, so had to add an Xmx memory parameter as well. Now it seems to behave better, although yesterday again a heap space error. Must be a leak somewhere. Will try to catch a dump, maybe I can find something.
All in all, maybe it is the docker environment that is no good match for songkong (image)…
One point if running on Debian then why not just use native linux install instead of docker?
I am testing on Synology, and the Docker build is primarily to support nas devices such as Synology/Qnap/Unraid without the difficulties of having to deal with al the varitions
Well the convenience and shielding of the docker is nice. Now the docker crashes, but the machine not…
And basically looks same, now I only need to crawl into the container to find out what is happening and can recreate in a flash.
Might consider making an lxc container on proxmox though…
But back on topic: behaviour then seems to be different on the synology. Will try to figure out why and what. Might be it also sets the workdir or something in the background. Can play around with that maybe.
Ok, but worth noting because Java based runs in a JVM so then even if SongKong does something wrong the JVM should protect your computer from crashing.
I think you were maybe hitting the issue described in this post 9.1.1 Docker on Unraid which is now fixed.
