Erlang/Elixir release start vs foreground

Questions / Help
,
#1

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.

#2

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 :slight_smile:

#3

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.

#4

Ok found it. There was some rogue old VPS running the app (not really rogue, but that makes my mistake sound less bad :wink: ).

No issue at all!

1 Like
#5

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.

5 Likes
#6

Interesting! So it is better to just run releases using foreground?

1 Like
#7

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

1 Like
#8

I came across this thread while looking into a mix release issue I’ve run into recently.

Basically, I can start the release with start, but strangely, both daemon and daemon_iex do not produce any output whatsoever.

Not even an error message.

Looking around online, I found this Github issue for a Distillery bug:

Which sounded pretty similar to the Mix Release issue I have.

Looking at what you’ve written, it sounds like start should be preferred to daemon anyway.

But might you have any idea about what’s breaking the daemon script?

#9

Sorry, just saw your question now. No idea however.

#10

No worries. There’s a resolution of some kind in this thread - Mix release starts with 'start' but not with 'daemon'

Our Sponsors

© Copyright Elixir Forum | Terms | Privacy & Cookies

Elixir Forum