Elixir: Mix release starts with 'start' but not with 'daemon'

[dynamite-ready]

Environment

• Elixir 1.9.1 (compiled with Erlang/OTP 20)
• Ubuntu 16.0.4 (via VirtualBox)
• Windows 8

Current behavior

I have an Mix release executable that works fine when started normally (_build/dev/rel/test/bin/test start), but appears not to run when launched as a daemon (_build/dev/rel/test/bin/test daemon). Is this a problem that others have encountered?

When I start it explicitly with start it initialises with no errors, and works as expected.
i.e, The output looks like the following:

=PROGRESS REPORT==== 5-Nov-2019::07:29:57 ===
          supervisor: {local,sasl_safe_sup}
             started: [{pid,<0.552.0>},
                       {id,alarm_handler},
                       {mfargs,{alarm_handler,start_link,[]}},
                       {restart_type,permanent},
                       {shutdown,2000},
                       {child_type,worker}]

etc...

But when started with daemon or daemon_iex it starts with no output and performs none of the actions I expect it to. In fact, the command acts like a no-op on the shell.

Further more, no output of any kind is redirected to the tmp folders, which is making this issue extremely hard to debug.

This happens with any Mix Release I create. In fact, the minimum code sample needed to reproduce the issue on my machine appears to be the following:

mix new test
cd test
mix release
_build/dev/rel/test/bin/test daemon

For the record, my issue appears to be very similar to this one submitted for the Distillery project:
https://github.com/bitwalker/distillery/issues/59

Expected behavior

When running _build/dev/rel/test/bin/test daemon I should either see some error output on the CLI, or output to the either the release tmp/log folder, or tmp/pipe folder.

[josevalim]

Daemon is not supported on Windows. We say so in the documentation but we should make it raise if you use said flag, to make it clearer. Thanks for the report.

[dynamite-ready]

@josevalim - Even within a VM?
Appreciate the reply, btw, at least it helps me to consider my options.

[josevalim]

@dynamite-ready oh, I misread it as you tested both, but it failed on the Windows one (not that you said this, it was just my imagination).

Can you try this outside of a release:

iex --pipe-to tmp/pipe/ tmp/log/
to_erl tmp/pipe/

If this works, then it is most likely a release issue. If it doesn't work, then it is either an Erlang issue or an OS issue.

Also, can you please paste which commands you are using to verify the pipe/tmp directories after you call daemon? ps -aux does not list any BEAM process in said cases? I want to rule out the daemon being started, but running somewhere unexpected.

[dynamite-ready]

When running:

iex --pipe-to tmp/pipe/ tmp/log/
to_erl tmp/pipe/

I receive the following message:

No running Erlang on pipe tmp/pipe/erlang.pipe: No such file or directory

Before this, I'd tried pgrep beam and pgrep epmd to track down any associated processes. I also tried looking through the process lists returned by top and lsof, but couldn't find any beam or epmd references.

Will be able to get back online later today, if there's anything else you'd like me to try here.

Thanks again for looking into this.

[josevalim]

Thanks @dynamite-ready for the follow up. So far we have ruled out this is not a release issue. Let's go one step deeper!

Can you please try:

$ mkdir -p tmp/pipe/
$ mkdir -p tmp/log/
$ run_erl -daemon tmp/pipe/ tmp/log/ iex
$ to_erl tmp/pipe/

If that also doesn't work, let's try this:

$ mkdir -p tmp/pipe/
$ mkdir -p tmp/log/
# Without -daemon
$ run_erl tmp/pipe/ tmp/log/ iex
# And then in another tab
$ to_erl tmp/pipe/

[dynamite-ready]

When attempting to run the second collection of commands, this line:

run_erl tmp/pipe/ tmp/log/ iex

Returns the following error:

run_erl:355 [13155] Tue Nov  5 19:47:20 2019
errno=1 'Operation not permitted'
Cannot create FIFO tmp/pipe/erlang.pipe.1.r for writing.

So I'm wondering if this might be a permissions issue?

[josevalim]

Awesome! It is either a permission issue or pipes are not supported within
the VM. Now we have to figure out why this was not reported properly in the

first place.

José Valimwww.plataformatec.com.br
http://www.plataformatec.com.br/Founder and Director of R&D

[dynamite-ready]

Great! Thanks for the help in resolving this @josevalim. Very much appreciated, as I know you're busy. :]

Would you like me to close this issue, or do you plan to leave it open to address docs and error handling issues?

[josevalim]

Yeah, I am hoping we can improve the error reporting. I will close once we

are done, thanks for asking.

José Valimwww.plataformatec.com.br
http://www.plataformatec.com.br/Founder and Director of R&D

[josevalim]

One last question: can you try calling mkfifo pipe and let us know if it works?

[dynamite-ready]

That command returns:

mkfifo: cannot create fifo 'pipe': Permission denied

I think you're right. This is looks a lot like a permissions issue, probably related to the shared folders feature on VirtualBox.

[OvermindDL1]

I think you're right. This is looks a lot like a permissions issue, probably related to the shared folders feature on VirtualBox.

Oh that definitely won't work, the shared folders of VBox are extremely limited in functionality. Systems should not be run 'on' them, only raw files transferred across them.

[josevalim]

@dynamite-ready a shared folder means the pipe also has to be valid on the Windows side of things and Windows does not support pipes.

I have checked our scripts and we do check if we have write permission directory. We don't preemptively check if we can create a pipe. So the check only happens when the program starts and since it is running as a -daemon, we don't get the reports.

We could try to create a pipe before and then delete it, but I am not sure if it is a good idea.

Thoughts?

[OvermindDL1]

We could try to create a pipe before and then delete it, but I am not sure if it is a good idea.

It's a bit churny on the filesystem, but nothing else is coming immediately to mind on how else to check it...

[michalmuskala]

Would it be somehow possible for the daemon mode to wait with returning until the system is started?

[josevalim]

@michalmuskala we would need to propose that to the OTP team.

Our best option for now is to test it ourselves and it seems the only way to test it is by churning the OS. There is no way to ask the OS for its capabilities. So for now I will mark this as unresolved and we can revisit it later if more people are running into this issue. Although ideally we would move the solution upstream.

Thanks everyone!