Some release-related watchdog enabled by default?

Olivier Boudeville olivier.boudeville@REDACTED
Sun Aug 2 12:50:07 CEST 2020


Hi,

Apparently, when running a release (at least if it was generated with 
latest stable rebar3/relx and Erlang/OTP 23.0) as a daemon (with 
run_erl), and even if not using specifically 'heart', a local UNIX 
process keeps on trying (once per second!) to connect to the 
corresponding VM.

In my case, the release changes its cookie at start-up (based on an 
application-level configuration file) and this may explain why, in the 
erlang.log.* file, a line such as:

(XXX@REDACTED)1> =ERROR REPORT==== 2-Aug-2020::12:17:46.042486 ===
** Connection attempt from node '24FIMJ0T6I9HU@REDACTED' rejected. Invalid 
challenge reply. **

is output each and every second (such a watchdog being thus unable to 
connect, as it is presumably using the original cookie)

Here are my questions:

- what Erlang/OTP/relx/rebar3 component is responsible for this, and is 
it really useful - especially if no specific heart behaviour is defined?

- how can this be fixed? (preferably disabling these connection attempts 
for good; otherwise telling such component which cookie to use in order 
to poll properly)

- is it something new? With earlier releases (pre-23.0?) of the same 
codebase, such a behaviour was not noticed [1]

If ever it mattered, this release relies on a non-standard EPMD port and 
is run through authbind as a low-privileged user.

Thanks in advance for any hint!

Best regards,

Olivier.

PS: this question had already been posted a while ago in 
https://www.rebar3.org/discuss/5ec58fa5ffbfc3018ed2eab9 yet did not 
receive an answer.

[1] It may have happened roughly when releases switched (for some 
reason, and unless I am mistaken) from being executed with 'start' to, 
now, either 'foreground' or 'daemon'.

-- 
Olivier Boudeville



More information about the erlang-questions mailing list