Por que o tempo de execução Erlang (ou RabbitMQ) escuta em uma porta UDP aleatória?

Question

Após uma atualização para o RabbitMQ 3.7.8 e o Erlange 21.1 (servidor do centOS 6), o netstat mostra que o beam.smp está escutando em uma porta UDP aleatória em todas as interfaces:

~$ sudo netstat -pnul | grep beam
udp        0      0 0.0.0.0:45224          0.0.0.0:*             7320/beam.smp

Essa porta está mudando a cada reinicialização e não é fechada ao interromper o aplicativo, mas é alterada quando o usuário inicia:

~$ sudo rabbitmqctl stop_app
Stopping rabbit application on node rabbit@host ...
~$ sudo netstat -pnul | grep beam
udp        0      0 0.0.0.0:45224          0.0.0.0:*             7320/beam.smp
~$ sudo rabbitmqctl start_app
Starting node rabbit@host ...
 completed with 7 plugins.
~$ sudo netstat -pnul | grep beam
udp        0      0 0.0.0.0:51001          0.0.0.0:*             7320/beam.smp

• Desativar todos os plug-ins não altera esse comportamento, então acho que isso não está relacionado ao plug-in.
• O tcpdump não mostra nenhuma atividade nessa porta.
• Não consigo encontrar nenhum vestígio disso na documentação do RabbitMQ.
• Não consigo encontrar nada relacionado a isso na Internet
• digitando o código de "rabbitmq-server" para "udp" não dá muita informação

A questão principal é para que é essa porta usada? Como corolário, é possível configurar isso?

    

Answer 1

Parece-me que é uma porta limitada pelo módulo syslog_logger, proveniente desta dependência do RabbitMQ:

link

Parece que, por padrão, ele é iniciado no nó RabbitMQ e, quando é inicializado, é ligado a uma porta aleatória:

A dependência: link

A linha onde a porta está aberta: link

De acordo com os documentos, esse recurso é desabilitado por padrão, mas o aplicativo Erlang é iniciado. Eu acho que seria melhor se o aplicativo não for iniciado quando estiver desabilitado.

Se você quiser verificar por si mesmo, você pode fazer isso:

Inicie um shell remoto na VM Rabbit Erlang:

% Start remote console
erl -sname test -remsh rabbit@$HOSTNAME
% Get all the port infos from the Erlang VM
PortInfos = lists:map(fun erlang:port_info/1, erlang:ports()).
% print the result
rp(PortInfos).
% Investigate the list for one which has the {name, udp_inet} line
% something like this: 
 [{name,"udp_inet"},
  {links,[<0.77.0>]},
  {id,9568},
  {connected,<0.77.0>},
  {input,0},
  {output,0},
  {os_pid,undefined}]
% And from this you can get the linked process, and see that it is a syslog_logger process
rp(erlang:process_info(erlang:list_to_pid("<0.77.0>"))).

% The result will be something like this
[{registered_name,syslog_logger},
 {current_function,{gen_server,loop,7}},
 {initial_call,{proc_lib,init_p,5}},
 {status,waiting},
 {message_queue_len,0},
 {messages,[]},
 {links,[#Port<0.1196>,<0.76.0>]},
 {dictionary,[{'$initial_call',{syslog_logger,init,1}},
              {'$ancestors',[<0.76.0>,<0.75.0>]}]},
 {trap_exit,false},
 ......]

Você pode ver a parte $initial_call , ele diz qual é o módulo.

Atualmente, não parece que esse comportamento possa ser controlado. O código só faz o envio, nenhum recebimento é implementado no módulo como eu posso ver.