More flexible cookie handling by relx?

[olivier.boudeville@REDACTED]

Hi,

(I cannot currently answer directly to the "Some release-related 
watchdog enabled by default?" thread, see 
https://erlang.org/pipermail/erlang-questions/2020-August/099852.html - 
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 
investigate).

Anyway, regarding the original problem, the cause of the unexplained 
"one connection attempt to the VM per second" lies probably in relx, 
precisely here: 
https://github.com/erlware/relx/blob/86ad0a3e9a9430c4537273397e8de258f1ce0721/priv/templates/extended_bin#L716 
; 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
			do
				sleep 1
			done

			relx_run_hooks "$POST_START_HOOKS"

		fi

(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 
here: 
https://github.com/erlware/relx/blob/86ad0a3e9a9430c4537273397e8de258f1ce0721/priv/templates/extended_bin#L650

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 [1].

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 
RELX_OVERRIDE_COOKIE variable.

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,
Best regards,

Olivier.

[1] 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).