Unable to start docker container with phoenix app using sqlite

Phoenix Forum Questions / Help
, ,
1

Hi,

I am having some trouble running a phoenix app in a docker container when using a sqlite database.
I have tried generating a brand new app with

mix phx.new --database sqlite3 phoenix_docker_test

generated a dockerfile with

mix phx.gen.release --docker

build the image with

docker build . -t phoenix_docker_test

created an empty database file and tried starting a container with

docker run -it --rm -e DATABASE_PATH=/srv/data.db -e SECRET_KEY_BASE=KEY_GENERATED_WITH_PHX.GEN.SECRET -p 4000:4000 -v (pwd)/data.db:/srv/data.db phoenix_docker_test

Sometimes the container just stops without output and sometimes I get

Fatal error in erl_drv_mutex_destroy(): Invalid argument [22]

I then tried creating a new project with

mix phx.new --no-ecto phoenix_docker_test

and did the same steps as before. This works just fine.

Anybody got any ideas?

Thanks!

2

I have the exact same issue and no idea what causes this. I scared it might relate to different host and docker systems. I am running on an ubuntu host and the images are based on debian. Somewhere in the docs it is mentioned, that different OSes use different mutex mechanisms. I fear that this is the issue here.

3

Okay, in my case the issue were invalid file / folder permissions. My docker instance was using root user by default. Phoenix uses the nobody user by default. So, when I created a docker volume via my compose file, the folder was created as root and my elixir app couldn’t write to it, due to permission issues.

Just in case someone else stumbles upon this post.

1 Like
4

I just wanted to follow this up and say that in my case it was actually a non-existent SQLite database. It worked as root for me, which was confusing, but I realized later that this is because Ecto attempted to create the sqlite database given it didn’t exist (and ran into its own permissions issue).

1 Like
5

This issue was brought to my attention here:

I’ll work to get this resolve soon.

2 Likes
6

I finally obtained some free time and resolved this issue.

It had to do with the destructor in the NIF trying to pass a stale pointer to erlang to free a mutex lock.

1 Like