I wonder if somebody could provide me with some insights on the difference between APP/bin/APP start and APP/bin/APP foreground, apart from the obvious (daemon like behaviour vs direct output).
We have some strange behaviour in our app when ran with ‘start’ (from using edeliver) rather than with foreground. More specific, we have some tasks running with Quantum and when using start they are registered and run multiple times (typically twice) and they also use old stale code (an outdated Ecto schema). When starting the app with foreground everything runs fine.
For now we only see this behaviour on our staging server, but since staging and prod are almost identical we are stressing deploying to production.
Could you be running more than one instance of the application at once? You could have the previous version and the current version both running in the background at the same time. This would explain the multiple jobs and the old code. It is easy to lose track of background processes I find
There should not be other differences, so I agree with @lpil that you might have multiple BEAM instances running. Maybe the problem is in the place invoking APP/bin/APP, which somehow doesn’t properly handle the start scenario, where the command returns immediately. Who is starting the release? Are you using e.g. systemd? In such case, IIRC, foreground should be used, not start.
While unrelated to your issue here I figured I should include the usual rant about start and the differences from foreground:
start is poorly named. With the new release functionality being added to mix this is luckily fixed, Jose has named it daemon instead of start.
The daemon created by start will fsync on every log line written which can become a bottleneck. Unless you really need the functionality of a pipe you can attach to I advise against ever using it.
Eventually rebar3 and relx will rename it, this hasn’t been done simply for backwards compatibility that goes back to the original rebar reltool scripts. Hopefully distillery will also rename it.
).
