More flexible cookie handling by relx?
Tue Aug 11 13:35:45 CEST 2020
(I cannot currently answer directly to the "Some release-related
watchdog enabled by default?" thread, see
hence this new thread)
Thanks Tristan for your answer. I was not aware that 'foreground' was to
be preferred to 'daemon' when running a release (currently I have an
issue with the former that does not show up with the latter, I will
Anyway, regarding the original problem, the cause of the unexplained
"one connection attempt to the VM per second" lies probably in relx,
; in daemon mode, if having switched cookie at runtime, such rpc
interactions are bound to fail endlessly and block the operations.
A quick work-around (apparently many releases run with the
--relx-disable-hooks option anyway?) would be to perform this polling
iff there are post start/stop hooks defined, like in:
# wait for node to be up before running any hooks:
if [ -n "$POST_START_HOOKS" ]; then
while ! erl_rpc erlang is_alive > /dev/null 2>&1
(and to do the same for post stop hooks)
Another solution (maybe better, in the sense that this would re-enable
all rpc-based functionalities for that release script in spite of a
runtime change in the cookie) could be to provide the user with the
possibility of specifying a cookie through an environment variable when
running the resulting release script; this would take place typically
If, say, the RELX_OVERRIDE_COOKIE environment variable was set to such a
"top-priority" cookie, then it would be used, otherwise the current
cookie logic would be used .
Then for example start/stop scripts that are run through systemd could
extract the right cookie from the application-specific configuration
file, and supply it to the release script thanks to that
Would these changes make sense? As they both could be useful, I could
submit a relx patch/pull-request introducing them?
Thanks in advance for any answer,
 The whole topic comes from the fact that one may not like the actual
cookie to be found by any logged-in user thanks to a mere 'ps -edf |
grep setcookie'; and if the cookie is specified in a configuration file
instead, it may better be specified in a single, application-specific
configuration file that is already needed for its own purposes (among
all other settings), rather than in a separate file in a different
location (such as vm.args).
More information about the erlang-questions