Zaczynając węzeł podrzędny Erlang w escript nie przy użyciu niestandardowego Erlang w Ubuntu 10.4

Question

Mam następujący escript:

#!/usr/bin/env escript 
%%! -name test_starter@127.0.0.1 

main(_) -> 
    NodeName = test, 
    Host = '127.0.0.1', 
    Args = "", 

    {ok, _Node} = slave:start_link(Host, NodeName, Args), 
    io:format("Node started successfully!"). 

Uruchamiając go na Ubuntu 10.04 uzyskać to:

$ ./start_slave 
Node started successfully! 
$ 

chcę zainstalować mój własny Erlang (najnowsza wersja, debug skompilowane pliki dla dializera itp.), ponieważ w magazynie Erlanga na Ubuntu brakuje niektórych funkcji. Umieściłem pliki binarne Erlang wewnątrz ~/Applications/bin. Uruchamianie Erlanga zwykle działa, a uruchamianie węzłów podrzędnych w powłoce Erlang działa również.

Jednak teraz mój eskryt nie działa. Po około 60 sekundach zwraca błąd:

$ ./start_slave         
escript: exception error: no match of right hand side value {error,timeout} 

Nawet gdybym zmienić pierwszy wiersz do escript aby wykorzystać moją wersję erlang, to nadal nie działa:

#!/home/user/Applications/bin/escript 

Węzeł podrzędny jest uruchomiony z wywołaniem erlang:open_port/2, które wydaje się używać sh, który z kolei nie czyta mojego pliku .bashrc, który ustawia moją niestandardową zmienną środowiskową PATH. Limit czasu wydaje się występować, gdy slave:start_link/3 czeka na odpowiedź węzła podrzędnego, co nigdy nie ma miejsca.

Jak mogę przetasować własną instalację Erlanga i uruchomić węzły podrzędne w escriptach w systemie Ubuntu 10.4?

Aktualizacja: Próbowałem dodać ścieżkę do mojego zwyczaju Erlang wewnątrz /etc/environment (gdzie oryginalna PATH w Ubuntu jest ustawione), ale to niczego nie zmienia ...

Aktualizacja 2: Przyjmowanie jedynej udzielonej odpowiedzi (nawet jeśli nie rozwiązało problemu). Wersje Ubuntu i Erlang są nieco stare i może to już nie być problem.

Answer 1

Czy to możliwe, że węzeł podrzędny jest uruchamiany z inną instalacją Erlanga? Podane przyczyny powodują błąd przekroczenia limitu czasu w the documentation on slave nodes Widziałem "węzły Erlanga mają różne pliki cookie", co może, jak sądzę, wystąpić w tym przypadku.

W takim przypadku uruchomienie ps -FC erlang podczas oczekiwania na przekroczenie limitu czasu powinno pokazać procesy o różnych ścieżkach.