Is a boot script necessary for alternative distribution?

Questions / Help
1

I was reading the docs on alternative distribution because I want to try silly things with my Nerves devices.

It says that “in a real system” you want the module available in the boot script and that places some constraints on what it can depend on.

Here: How to Implement an Alternative Carrier for the Erlang Distribution — erts v15.1.1

My guess is that this assumes you want to establish the cluster immediately which would be the common case perhaps. For more dynamic clusters where it is fine if members come and go, because the clustering is non-critical, are there particular reasons to avoid this? It is mentioned as an option for debugging. Are there significant drawbacks there or is the documentation just a bit opinionated in usage of the functionality?

2

Not sure if I understand the question fully. That piece of documentation talks about assumptions that an alternative distribution implementation can make.

Boot script is absolutely necessary to run Erlang (Ericsson’s implementation), because it sets up paths, loads kernel modules etc… You don’t have to create your own boot script (although it is created when you make a release).

3

The question is essentially. If you make an alternative distribution method, is it fine to load that later, at runtime?

4

Load what?
When you run the distributed node, e.g. erl -name somename -proto_dist your_dist, your module must be available during kernel startup.

5

I am trying to go off of what the docs say:

The implementation can be debugged by starting the distribution when all the system is running, but in a real system the distribution is to start very early …

So presumably it can be loaded at runtime. If so, why is this not appropriate for a production system? Why should it start early? Is there some assumption made that I am missing? Could a distribution mechanism that is loaded later depend on other packages?

6

Yes it can, but you’d need to start the distribution manually, via net_kernel:start. It’s a relatively advanced technique, and you need to understand the implications.

7

That’s fair. I’ve certainly done that in tests and maybe even on some hobby devices.

Can I read more about the implications somewhere? :smiley:
I kind of assume it is mostly a problem if the clustering is of critical importance.

I am thinking of experimenting with it for Nerves devices, so embedded. And primary concerns are that they start, connect to their network and establish their connection to NervesHub for updates.

Attempting to cluster them would be a later concern and not nearly as critical. The way that passage is written I get the impression that it would be bad to do start clustering later and that it should only be used for debugging. And that seems like it might be an exaggeration. But it made me think that maybe there are performance penalties or other concerns that are non-obvious.

8

The way I read it, “some OTP applications may rely on distribution available prior to their startup”.

I can imagine that mnesia relies on node being distributed when the application start. So that if you’re using releases, you’d need to ensure that distribution starts before mnesia.

1 Like
9

That would make sense, yeah :slight_smile: