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

Hi all. First time creating a thread here, please be gentle!

I have an Mix release executable that works fine when started normally, but appears not to run when launched as a 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. 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.

Interestingly, the issue I believe I’ve encountered sounds very similar to the one found for Distillery on Github here:

So I suspect there could well be a shared underlying cause.
Any ideas, please?

Edit - Further details, I’d encountered this issue running Elixir 1.9.1 (compiled with Erlang/OTP 20), on Ubuntu 16.0.4 via VirtualBox on Windows. I know VM setups can occasionally mess with common OS settings, and security features, so if that might be a potential issue, advice will be welcome.

1 Like

Hmm, what if you create a file in your Application startup, before any of ‘your’ supervisors spin up, does it get created?

Is your logger outputting to syslog or somewhere? Anything there?

So far, I’ve looked to ./tmp/log, and also ./tmp/pipe, but have found nothing there. By creating a file, do you mean actually creating a file, or just try to produce some form of IO?

Do you actually output to ./tmp/log? And if so what is the line of code that does that and in what function in what module is it located?

Creating a file is enough. A logger ‘might’ be enough if it’s linked to something persistent like journald/syslog or a file output or so. You won’t be able to IO.puts or log to the screen or so since it’s a daemon (no stdin/stdout). ^.^

.tmp/log is where the Mix Release startup script redirects IO to by default when run in daemon mode:

Line 75 in build/dev/rel/my-app/bin/my-release

    start "elixir" --no-halt --pipe-to "${RELEASE_TMP}/pipe" "${RELEASE_TMP}/log"

Hmm that’s a Mix Release thing, I use Distillery still and it doesn’t do that.

I’m wondering if this is an early version issue too. Tbf though, Mix Releases do appear to be a little more user friendly than Distillery. Plus it’s one less dependency (I’m one of those devs…).
As it does run in start mode, I could just use systemd and make a service of the app instead…

But I’d really like to know why one mode works, and the other mode doesn’t.

Issues like that are a code smell. But in this case, I’m not entirely sure if that issue is in my code, as I can reproduce the issue by merely creating a fresh Mix project with barely any code, except for the releases config (thank to help from the Elixir Slack channel).

Added a Github issue:

If anyone’s encountered the same, or a similar thing, would be cool to hear from you.

Wondering if this is actually a BEAM level issue.


Well lets see what folder permission you have. In a terminal window:

stat /tmp/log   


stat /tmp/pipe

I want to see what Access: (#) Uid: (#/user) Gid: (#/user )

What I think is going on is that this program should install its own user and file privileges, and somehow that got overlooked or somehow didn’t happen when it was installed.

If this program doesn’t install its own user, it will not run in daemon mode according to the deamon Unix module in the OS (Ubuntu). The only way for it to run without setting as its own user is to run it as root. But I would not advise that.

1 Like

Just checked daemon mode with one of my apps on Ubuntu 18.04, seems to work fine - the app is working and there is output in the tmp directory (just to be clear: it’s not /tmp, but a ./tmp in the release dir).

So if there is an issue it might have to do with the OS running in a VM.

1 Like

Most likely its the file permissions. Did you run stat on your directories? ( stat /.tmp/log)

.tmp is a hidden folder in Linux. All folders and files that start with a period (.) has the hidden attribute applied.

.tmp is a hidden folder in Linux. All folders and files that start with a period (.) has the hidden attribute applied.

It’s a relative path, the tmp directory is located in the project root _build/[env]/rel/[release name]/tmp/log.

yes, they all spawn it that way, but lets get back to the person that has trouble, which file permissions being out of wack is not out of the norm for linux, especially for it being a source code and not packaged and in a distro channel.

I did originally suspect a permissions issue (as with many of the best linux PITA’s). Also, with Windows VirtualBox instances, symlinks can be a problem.

Is there any part of the call stack, either when running or building a release, that relies on symlinks?

@sd4code - Will definitely check file permissions on all relevant folders when I’m back on my machine, later.

JS Node requires a symbol link for script compiling. Which should be documented as:

ln -s /usr/bin/nodejs /usr/bin/node

Quickly searching the install pages, its noted in the phoenix install page:

The difference between running it on the command line vs a process is that the user is different. On the command line, the user is the user account . The daemon, the program is the user and should have a user account that at least assigned to the same file access group as the user, but usually set as a separate user group. The rules for a program to run as a daemon are: its own user account, and must not be root or a part of root user group.

Looks like there might be a resolution to this ticket here:

So, if anyone’s running into issues with starting a Mix release as a daemon on a VirtualBox instance, it might be an issue you have to look out for.

Thank you for the help. :+1:

1 Like