jeroenbourgois
Hi!
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.
Where Next?
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Practical resources that improve the lives of professional developers.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #ai
- #elixirconf-us
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Bringing learning, work and compliance together since 1987.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 9- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
lpil
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
sasajuric
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 thestartscenario, where the command returns immediately. Who is starting the release? Are you using e.g. systemd? In such case, IIRC,foregroundshould be used, notstart.jeroenbourgois
Ok found it. There was some rogue old VPS running the app (not really rogue, but that makes my mistake sound less bad
).
No issue at all!
tristan
While unrelated to your issue here I figured I should include the usual rant about
startand the differences fromforeground:startis poorly named. With the new release functionality being added to mix this is luckily fixed, Jose has named itdaemoninstead ofstart.The daemon created by
startwill 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.
jeroenbourgois
Interesting! So it is better to just run releases using
foreground?tristan
Right. Using start should only be when the user discovers they need some of the run_erl functionality http://erlang.org/doc/man/run_erl.html
dynamite-ready
I came across this thread while looking into a
mix releaseissue I’ve run into recently.Basically, I can start the release with
start, but strangely, bothdaemonanddaemon_iexdo not produce any output whatsoever.Not even an error message.
Looking around online, I found this Github issue for a Distillery bug:
https://github.com/bitwalker/distillery/issues/59
Which sounded pretty similar to the Mix Release issue I have.
Looking at what you’ve written, it sounds like
startshould be preferred todaemonanyway.But might you have any idea about what’s breaking the
daemonscript?jeroenbourgois
Sorry, just saw your question now. No idea however.
dynamite-ready
No worries. There’s a resolution of some kind in this thread - Mix release starts with 'start' but not with 'daemon'