Container not starting when bind-mounting

[simonszu]

I am using bind mounts for persistence, since i have my data on a specialized location. Since bind mounts override the content in the container, bind-mounting /etc/prosody effectively removes /etc/prosody/prosody.cfg.lua from the scope of the container. This results in failing startup for the container.

Other containers copy essential files to a template directory and check in their entrypoint file, if the desired files are available in bind-mounts, and copy them to the location if needed. It would be great if the prosody container does this as well, since the only way for me to resolve this is to copy a prosody.cfg.lua from somewhere else and restart the container.

[mwild1]

Hi @simonszu, thanks for the report.

I'm curious to understand your problem a bit more. You are bind-mounting /etc/prosody, but not providing a config file? If that's right, can you explain why?

[simonszu]

Yes, i am bind-bounting with calling -v /data/prosody/config:/etc/prosody. I did not know that i had to provide a config file, since it isn't explained in the README. If i have to manually provide it, i will do this, of course, but where to get it from?

I am used to a behaviour by other containers, which populate the perhaps empty config directory (due to bind mounting) with some default config, so that the container will at least start successfully, and so that the users have something to work on and to tweak to their desired settings.

I assume that this image will have an /etc/prosody/prosody.cfg.lua after building, so i have to execute a shell in the running container, copy the file to the host, stop the container, re-create it with a bind mount, and populate the mount with the file i have salvaged from the previously running container? That's not very convenient.

[Zash]

You can find the default config in our source repository and it would have this patch applied.

[mwild1]

I'm going to close this, because the container does start ok if you give it a config file. But I opened #53 to investigate using environment variables in the default config.