VRMS Connection refused: caçando um vazamento de file descriptors no hms.service

Se você gerencia o vSphere Replication pela API e está enfrentando erros intermitentes de Connection refused na porta 8043, provavelmente é isso que está acontecendo. O erro se parece com isto:

Unable to retrieve pairs from extension server at https://vrms-appliance.example.local:8043.
Unable to connect to vSphere Replication Management Server at https://vrms-appliance.example.local:8043.
Reason: https://vrms-appliance.example.local:8043 invocation failed with
"java.net.ConnectException: Connection refused", ErrorCode=2.99.2,
OpID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

O hms.service (o processo Java do vSphere Replication Management Server) escuta na porta 8043. Quando ele não está lá, as chamadas de API falham. O processo não estava ausente por causa de um problema de rede — ele estava reiniciando.

Seguindo o contador de reinícios

#

O primeiro número útil veio do systemctl show:

root@vrms-appliance [ ~ ]# systemctl show hms.service --property=NRestarts
NRestarts=13

13 reinícios desde o último reboot do VRMS, 13 dias antes — aproximadamente uma queda por dia. O hbrsrv.service (o motor de replicação) esteve rodando continuamente durante esses mesmos 13 dias, então o appliance em si estava estável. O hms era quem estava ciclando.

O journal mostrava o mecanismo:

Apr 14 11:16:28 vrms-appliance systemd[1]: hms.service: Watchdog timeout (limit 5min)!
Apr 14 11:16:28 vrms-appliance systemd[1]: hms.service: Killing process 1725075 (java) with signal SIGABRT.
Apr 14 11:16:29 vrms-appliance systemd-coredump[2582430]: Process 1725075 (java) of user 980 dumped core.
Apr 14 11:16:29 vrms-appliance systemd[1]: hms.service: Main process exited, code=dumped, status=6/ABRT
Apr 14 11:16:29 vrms-appliance systemd[1]: hms.service: Failed with result 'watchdog'.
Apr 14 11:16:34 vrms-appliance systemd[1]: hms.service: Scheduled restart job, restart counter is at 13.

O watchdog do systemd mata o processo se ele deixa de responder às verificações de saúde dentro do intervalo configurado (5 minutos aqui) e o reinicia. O hms estava perdendo essa janela de forma consistente.

Too many open files

#

O log de auditoria do kernel apontava para o processo java:

Apr 14 11:16:28 vrms-appliance kernel: audit: type=1701 audit(1776176188.958:11942): auid=4294967295
uid=980 gid=980 ses=4294967295 subj=unconfined pid=1725075 comm="java"
exe="/usr/java/jre-vmware/bin/java" sig=6 res=1

E o hms-stderr.log tinha o erro de fato, se repetindo em um intervalo de cerca de 2 segundos por vários minutos antes da queda:

Apr 14, 2026 11:16:08 AM org.apache.tomcat.util.net.Acceptor run
SEVERE: Socket accept failed
java.io.IOException: Too many open files
    at java.base/sun.nio.ch.Net.accept(Native Method)
    at java.base/sun.nio.ch.ServerSocketChannelImpl.implAccept(Unknown Source)
    at java.base/sun.nio.ch.ServerSocketChannelImpl.accept(Unknown Source)
    at org.apache.tomcat.util.net.NioEndpoint.serverSocketAccept(NioEndpoint.java:449)
    at org.apache.tomcat.util.net.Acceptor.run(Acceptor.java:129)

A thread acceptor do Tomcat tentava aceitar novas conexões e batia no limite de file descriptors. Quando não dá para aceitar conexões, o processo também não consegue responder à verificação de saúde do watchdog do systemd — então o systemd o mata.

Cerca de 2,5 horas depois do último reinício, o processo já estava com 14.472 file descriptors abertos, contra um limite de 20.000:

root@vrms-appliance [ ~ ]# cat /proc/2582480/limits | grep -i "open files"
Max open files            20000                20000                files

root@vrms-appliance [ ~ ]# ls /proc/2582480/fd | wc -l
14472

72% do limite consumidos em menos de três horas. Nesse ritmo, o processo bate no teto bem antes do fim do dia.

Chegando ao schedule-health-checks

#

Um engenheiro da Broadcom sugeriu olhar o schedule-health-checks no hms-configuration.xml:

root@vrms-appliance [ ~ ]# cat /opt/vmware/hms/conf/hms-configuration.xml | grep "<schedule-health-checks>"
<schedule-health-checks>true</schedule-health-checks>

O schedule-health-checks diz ao hms para consultar periodicamente a saúde da replicação em todas as VMs protegidas. Cada ciclo abre conexões que nunca são fechadas corretamente — então os file descriptors se acumulam até o processo ficar sem eles e cair.

Como verificar se você é afetado

#

Execute estes comandos no seu appliance VRMS via SSH.

1. Verifique se o hms.service vem reiniciando:

systemctl show hms.service --property=NRestarts

Qualquer valor acima de 0 significa que o serviço caiu e foi reiniciado desde o último reboot do appliance. Compare com o uptime:

uptime

Se o appliance está no ar há semanas, mas o NRestarts está na casa das dezenas, alguma coisa está ciclando o hms regularmente.

2. Confirme que os reinícios são causados por timeout do watchdog:

journalctl -u hms.service --no-pager | grep -i "watchdog\|Failed with result"

Você está procurando linhas como estas:

hms.service: Watchdog timeout (limit 5min)!
hms.service: Failed with result 'watchdog'.

Se você vir essas linhas, o processo está travando — e não caindo por um motivo não relacionado.

3. Verifique o uso atual de file descriptors:

Obtenha o PID do processo hms em execução:

systemctl show hms.service --property=MainPID

A saída vai se parecer com:

MainPID=2582480

Use esse número nos dois próximos comandos — substituindo 2582480 pelo valor que você obteve:

cat /proc/2582480/limits | grep -i "open files"
ls /proc/2582480/fd | wc -l

O primeiro comando mostra o limite configurado (Max open files). O segundo mostra quantos file descriptors o processo tem abertos no momento. Se a contagem do segundo comando já é uma fração grande do limite — e o serviço reiniciou recentemente — o vazamento está ativo.

4. Confirme que o parâmetro está habilitado:

cat /opt/vmware/hms/conf/hms-configuration.xml | grep "<schedule-health-checks>"

Se ele retornar <schedule-health-checks>true</schedule-health-checks>, você está sofrendo com este problema.

Correção

#

Passos:

1. Faça um snapshot do appliance primeiro.

2. Entre no appliance por SSH e pare o hms.service:

   systemctl stop hms.service

3. Edite o arquivo de configuração:

   vi /opt/vmware/hms/conf/hms-configuration.xml

   Altere:

   <schedule-health-checks>true</schedule-health-checks>

   Para:

   <schedule-health-checks>false</schedule-health-checks>

4. Aguarde aproximadamente dois minutos para que os sockets abertos expirem e sejam fechados.

5. Inicie o serviço:

   systemctl start hms.service

6. Confirme que o NRestarts agora é 0:

   systemctl show hms.service --property=NRestarts

   Você também pode verificar há quanto tempo o hms está no ar sem problemas:

   systemctl status hms.service | grep Active

Depois da correção

#

No dia seguinte, o NRestarts voltou a 0 e permaneceu assim.

root@vrms-appliance [ ~ ]# systemctl show hms.service --property=NRestarts
NRestarts=0

O engenheiro da Broadcom neste caso foi genuinamente prestativo — ele nos apontou o parâmetro schedule-health-checks e, depois de confirmarmos a correção, dedicou tempo para documentá-lo oficialmente. Esse tipo de acompanhamento merece ser destacado.

A Broadcom publicou a KB 437468 sobre este problema. A KB confirma a causa raiz: as conexões de verificação de saúde dos mapeamentos de Enhanced Replication nunca são fechadas corretamente, então os file descriptors se acumulam até o processo cair. Versões afetadas e corrigidas:

Atualizar para a versão corrigida elimina totalmente a necessidade do workaround do schedule-health-checks.