Elixir app runs locally in Docker, but not on the server

I am using Elixir 15.7 in my application with LifeView. I am implementing a polling mechanism using Elixir’s Process.send_after/3 function. This function schedules a message to be sent to the current process (self) after a specified interval, in this case, 6 seconds. The message being sent is :poll . When received, it triggers the handle_info(:poll, socket) function again, effectively creating a loop that continuously checks Firestore for an updated result. When the result becomes available, an event is triggered via a socket change.
I have two variables:

  • a boolean “is result available” and
  • a result field which is empty at first and gets filled when the bolean variable turns true

This works in a docker container on Localhost running on my laptop. However, it doesn’t work in a docker container on a plain new Ubuntu server. there, the polling runs only once initially but never gets triggered again. It does nothing, no error arises, but so the status change never happens and I am caught in a waiting mode forever.

I don’t understand where the difference comes from between a docker container running locally and one running on a cloud server.

Any ideas where I can look? Or, alternatively, how I can change the way I am attempting to receive the result that will work better?

Are there any configuration settings that can affect this? Perhaps something in your local configuration that is different than runtime.exs? Are you using any environmental variables for this?

Just for the record, I am comparing a local docker container with a docker container running on a cloud Ubuntu server, so it’s docker vs. docker, not necessarily comparing with running mix phx.server. So, what exactly could be different?

I am using environment variables, but they all seem to be correctly set, especially because all other parts of the app work.

I would also look into alternative implementations instead of polling.

I believe he’s asking if you’re using the :dev or :prod environment in your local container.

Right! Both production.

I sincerely believe the docker container is identical. Only the system around it is not.

Have you tried inspecting both containers with the dive tool?

What would i look for with this tool? It seems like this tool helps to inspect a docker container, but it doesn’t help me understand the system configuration for an identical docker container on two different systems.

I’d use it to make sure they’re identical is what I meant.

Is there anything specifically you would look for considering that I run docker build once on my device, then push, pull and run the same container?

The domain/IP is different, of course, but I don’t know what other change would be introduced in the process? I definitely did not make any other changes, I even repeated the process multiple times to be sure.

Since they are behaving differently, there could be a a difference in startup somewhere:

  • docker startup
  • docker mount points for volumes
  • environmental variables
  • runtime.exs

Then there’s the potential of perhaps send_after not working properly for different reasons. I’m not sure why sending a message to self wouldn’t work on a different system, but maybe there’s a reason.

I would attach a console to the process, run observer, or do some printf debugging to figure out where and why the 2nd message isn’t being processed. I can think of esoteric reasons involving epmd, but none really make any sense.

So there’s a lot of debugging left to do on this one.

I have tracked the problem down to the fact that the function
Process.send_after/3
which is responsible for the recurring event runs regularly locally, but on the cloud server, it gets only called once and then never again.

At this point you should code a very small GenServer and copy paste the source in iex on the cloud production machine and inspect what it does.

2 Likes

I have tracked down the problem, but will open a new thread, because it is a new topic. Thank you for your help!

So what was it?

A pre-condition failed to run the polling mechanism successfully. It is still unclear why this happened only on the server, but we rewrote the logic so that the precondition would always be fulfilled before polling starts.

1 Like