Trouble starting a remote node with ct_slave/start/3 on a remote host which uses kerl

Questions / Help
,
1

I have trouble starting a remote node with ct_slave/start/3 on a remote host which uses kerl. I guess this is because ct_slave doesn’t use an interactive shell. The remote host is a Debian 11 machine. Any suggestions?

1 Like
2

kerl is about building the Erlang/OTP libraries and runtime environment, and would be unrelated to how you interact with it.

I guess a first question is can you make regular Erlang nodes talk to each other across these hosts and is it only failing with ct_slave, or is it failing in general?

2 Likes
3

I do use ct_slave on a regular basis without a problem. Actually, ct_slave works fine from the host that has the kerl built Erlang instance. When using an interactive shell (ssh), .profile is executed which activates an Erlang instance

if [ -d "$HOME/kerl" ] ; then
    . "$HOME/kerl/23.3.4.18/activate"
fi

NB: I know, that’s an old version…

1 Like
4

I’m just saying, kerl is about building Erlang and has no impact on the networking stack in general. This is like going “it was built with makefiles, why isn’t it connecting?”. I think you’re looking at the wrong thing.

I am asking whether with computer A and computer B where you are trying to use ct_slave, you can get a regular Erlang shell, without ct_slave, to connect. So the question here is whether the issue is around ct_slave usage, or more broadly, the network between the two hosts and the ability for distributed Erlang to work.

I don’t think how you built Erlang is relevant unless one node is on a much newer version than the other.

2 Likes
5

There is no problem starting an interactive Erlang shell on the remote system because the .profile (or bashrc or something similar) file is executed. But with ct_slave, the file .profile is not executed because it is not an interactive shell. I have not yet found any other way in sshd that allows me to execute kerl activate when connecting via ct_slave. So it is mainly an sshd problem.

1 Like
6

Fixed it: I did overlook the first few lines in .bashrc which exited the script when not interactive. A quick fix was to add the next few lines in .bashrc:

case $- in
    *i*) ;;
      *)
        if [ -d "$HOME/kerl" ] ; then
            . "$HOME/kerl/23.3.4.18/activate"
        fi
        return;;
esac
1 Like