Some release-related watchdog enabled by default?
Sun Aug 2 12:50:07 CEST 2020
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
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 
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!
PS: this question had already been posted a while ago in
https://www.rebar3.org/discuss/5ec58fa5ffbfc3018ed2eab9 yet did not
receive an answer.
 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'.
More information about the erlang-questions