erlang / rebar3

Erlang build tool that makes it easy to compile and test Erlang applications and releases.
http://www.rebar3.org
Apache License 2.0
1.7k stars 518 forks source link

'rebar3 daemon' not working as 'rebar3 start' #2647

Open ziyouchutuwenwu opened 2 years ago

ziyouchutuwenwu commented 2 years ago

Pre-Check

Environment


Operating System: x86_64-pc-linux-gnu ERTS: Erlang/OTP 24 [erts-12.0] [source] [64-bit] [smp:6:6] [ds:6:6:10] [async-threads:1] [jit] Root Directory: /home/mmc/.asdf/installs/erlang/24.0 Library directory: /home/mmc/.asdf/installs/erlang/24.0/lib

Loaded Applications: bbmustache: 1.10.0 certifi: 2.6.1 cf: 0.3.1 common_test: 1.20.3 compiler: 8.0 crypto: 5.0 cth_readable: 1.5.1 dialyzer: 4.4 edoc: 1.0 erlware_commons: 1.5.0 eunit: 2.6.1 eunit_formatters: 0.5.0 getopt: 1.0.1 inets: 7.4 kernel: 8.0 providers: 1.8.1 public_key: 1.11 relx: 4.5.0 sasl: 4.1 snmp: 5.9 ssl_verify_fun: 1.1.6 stdlib: 3.15 syntax_tools: 2.6 tools: 3.5


Escript path: /home/mmc/dev/erlang/rebar3 Providers: app_discovery as auto clean compile compile cover ct deps dialyzer do edoc escriptize eunit get-deps help install install_deps list lock new path pkgs release relup report repos shell state tar tree unlock update upgrade upgrade upgrade version xref

$ rebar3 report "my failing command"

- Verify whether the version of rebar3 you're running is the latest release (see https://github.com/erlang/rebar3/releases)
- If possible, include information about your project and its structure. Open source projects or examples are always easier to debug.
  If you can provide an example code base to reproduce the issue on, we will generally be able to provide more help, and faster.

### Current behaviour ###

Describe the current behaviour. In case of a failure, crash, or exception, please include the result of running the command with debug information:

i run this cmd, zsh hung up.

bin/demo_release daemon


and run this in another shell, here is the result

bin/demo_release daemon_attach Node is not running!

checking process list

$ ps aux | grep erl mmc 5308 0.0 0.0 3880 1560 ? S 08:11 0:00 /home/mmc/.asdf/installs/erlang/24.0/erts-12.0/bin/epmd -daemon mmc 40391 0.0 0.0 3748 128 ? S 09:04 0:00 /home/mmc/.asdf/installs/erlang/24.0/erts-12.0/bin/run_erl -daemon /tmp/erl_pipes/demo_release@hp/ /home/mmc/projects/erlang/demo_release/_build/default/rel/demo_release/log exec "/home/mmc/projects/erlang/demo_release/_build/default/rel/demo_release/bin/demo_release" "console" '' --relx-disable-hooks mmc 40396 0.1 0.1 4253500 64856 pts/4 Ssl+ 09:04 0:00 /home/mmc/projects/erlang/demo_release/_build/default/rel/demo_release/bin/demo_release -K true -A30 -- -root /home/mmc/projects/erlang/demo_release/_build/default/rel/demo_release -progname home/mmc/projects/erlang/demo_release/_build/default/rel/demo_release/bin/demo_release -- -home /home/mmc -- -boot /home/mmc/projects/erlang/demo_release/_build/default/rel/demo_release/releases/1.0.0/start -mode embedded -boot_var SYSTEM_LIB_DIR /home/mmc/.asdf/installs/erlang/24.0/lib -config /home/mmc/projects/erlang/demo_release/_build/default/rel/demo_release/releases/1.0.0/sys.config -sname demo_release -setcookie 111111 -- -- console --relx-disable-hooks -- mmc 40680 0.0 0.0 2372 684 ? Ss 09:04 0:00 erl_child_setup 1024 mmc 44529 0.0 0.0 9592 2464 pts/6 S+ 09:11 0:00 grep erl



### Expected behaviour ###

Describe what you expected to happen.

wish the 'daemon' and 'daemon_attach' can work.
ferd commented 2 years ago

Is your release actually booting fine when using another mode like foreground ? We should debug if this is an issue with daemon mode or your release first.

ziyouchutuwenwu commented 2 years ago

hi, running rebar3 foreground, the behavior is the same as version 3.13

as you can see, i use manjaro and asdf to install erlang, my another laptop has the similar config, but rebar3 with version 3.17.0 works fine in daemon mode and daemon_attach mode, it seems to be strange.

is there anyway that i can provide some logs that can help to debug this issue?

ferd commented 2 years ago

yes, you can upload logs to github comments. Unless you meant a way to do it more privately?

ziyouchutuwenwu commented 2 years ago

when i execute rebar3 daemon or rebar3 daemon_attach, it just hangup, so i don't know how to get the log file and post it here

ferd commented 2 years ago

One thing I'd do to debug this manually is go look at the shell script that's generated, and try to echo the command as it would be executed, likely at: https://github.com/erlware/relx/blob/a146bee5ef7283a4860d6c68a067fe0f3dcdc321/priv/templates/extended_bin#L767-L781

If it hangs, chances are it's booting the app in daemon mode, and then it enters the loop to ping until it can reach the other end. This could either be a problem with the erl_rpc call itself (which you can test by calling it manually and looking for bad output), or while booting the instance. The command is defined at https://github.com/erlware/relx/blob/a146bee5ef7283a4860d6c68a067fe0f3dcdc321/priv/templates/extended_bin#L316-L344 and one thing you can try is setting the environment variable ERL_RPC=relx_nodetool, which will bypass using the erl_call executable shipping with OTP and make do with an escript instead.

MGreim commented 2 years ago

I think I have found a workaround or maybe the reason for the bug: if you try to start ./erl in /srv/www/cgi-bin-wf/wf/_build/prod/rel/wf/erts-11.1.8/bin where wf is the name of the program and application erl complains about a missing boot file. Here the message: cannot get bootfile,/srv/www/cgi-bin-wf/wf/_build/prod/rel/wf/bin/start.boot see crash dump below:

=erl_crash_dump:0.5
Mon Mar  7 15:09:15 2022
Slogan: init terminating in do_boot ({cannot get bootfile,/srv/www/cgi-bin-wf/wf/_build/prod/rel/wf/bin/start.boot})
System version: Erlang/OTP 23 [erts-11.1.8] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1]
Compiled: Thu Feb 25 12:29:31 2021

If you copy this start.boot from /srv/www/cgi-bin-wf/wf/_build/prod/rel/wf/releases/0.1.0

to

/srv/www/cgi-bin-wf/wf/_build/prod/rel/wf/bin

everything seems to work again!

I assume that something in erl has changed, because the start script (here in my application called wf) generated by rebar3 has not changed against version 10.6.4

I don't not so much about all the nitty-gritty of rebar3 / erl / erts so maybe someone may forward my findings to some real experts.

Regards Markus

abalazsik commented 8 months ago

In my case, the cause was having these two flags in my vm.args file:

This makes sense. My question would be; what is the correct way of starting an application, if I don't want to run the distribution layer?

EDIT: I mean it starts the application in the background, and works as expected. I can start it by issuing the same command that the script generates, but it would be nice if the script was able to handle applications like this.

ferd commented 8 months ago

you might want to start it as foreground but also pass in the -detached flag in vm.args. You'll want to store or track the pid somewhere to kill it at some point though because without a name you can't do much with it and interact in no way whatsoever.