Gateway do Hermes Agent reiniciando sem parar no systemd: o que significam –replace, –force e o código de saída 75

Fala aí, beleza? Tu deixou o Hermes Agent rodando como serviço na VPS, foi olhar o log e o gateway de um perfil está reiniciando em ciclo, não sobe ou se anexa a outro processo que tu nem lembrava que existia 😛

O código 75 pode indicar que uma unidade deve tentar novamente ao encontrar outro gateway no host. A primeira verificação é descobrir se existe um gateway ativo atendendo ao perfil. A issue #141567 documenta um caso em que as tentativas se repetiam sem nenhum gateway atender ao perfil.

Este guia cobre o que está na documentação de gateways multi-perfil, consultada em 2 de novembro de 2026, mais a issue oficial sobre o código 75.

O Hermes muda rápido, então confere os comandos na versão vigente antes de aplicar em produção, beleza?

Por que o gateway do Hermes sai com código 75 e o systemd reinicia em seguida

O gateway sai com 75 porque já existe um gateway hospedeiro ativo e o comando do teu perfil se anexou a ele, em vez de abrir um segundo processo

Na anexação, o hermes -p <nome> gateway run imprime o PID do hospedeiro e o conjunto de perfis que ele atende (o tal served set)

E por que não sai com 0?

Fora de supervisor, sai com 0 mesmo: anexou, mostrou o PID, terminou

Sob um supervisor de serviço (systemd, s6 ou launchd), a anexação termina com código 75

Que código é esse? Não é um erro: a issue do repositório oficial que documenta esse comportamento descreve o 75 como "a transient state and a service supervisor will retry": ou seja, um estado transitório que o supervisor de serviço vai repetir

Aí o supervisor espera um curto intervalo e tenta de novo, e de novo…

Confira nos logs se as novas tentativas resultam em um gateway atendendo ao perfil.

É como esperar na fila do caixa: tu não foi recusado, só não é a tua vez ainda 🙂

E se o perfil ainda não for atendido pelo hospedeiro?

Nesse caso, o comando pede ao hospedeiro que reescaneie a pasta profiles/ e se anexa quando a resposta incluir o perfil

Ele só recusa (com código diferente de zero) quando o hospedeiro não pode passar a atender aquele perfil

Quando o 75 NÃO é normal: o bug aberto no Hermes 0.22.1

A issue #141567 descreve um caso em que o código 75 se repetia sem nenhum gateway de fato atender ao perfil.

O relato descreve um reboot seguido por 9.152 reinícios em 33 horas. Segundo o autor da issue, o registro antigo do gateway apontava para um PID que outro processo passou a usar. No log, a mensagem recorrente indicava que já existia um gateway dono do host e que ele ainda não havia informado os perfis atendidos.

O que fazer

Identifique quem está atendendo ao perfil antes de modificar a unidade.

Monitore a contagem de reinícios e o log da unidade. Confira se algum gateway ativo atende ao perfil antes de atribuir a sequência de saídas com código 75 ao comportamento esperado.

Tome cuidado: alerta disparando só por causa de um 75 pontual é o caminho mais rápido pra alguém "consertar" o que não estava quebrado haha. Mas reinícios acelerados por horas, com essa mensagem insistindo no journal e nenhum processo gateway run de fato vivo, merece investigação

Duas unidades do gateway subindo juntas: quem decide qual processo roda

Quem decide é a trava do hospedeiro (host lock)

Quando duas unidades sobem ao mesmo tempo, pode acontecer de nenhuma das duas enxergar um processo hospedeiro ativo

Aí a trava escolhe qual roda, a perdedora sai com 75 e, na nova tentativa do supervisor, se anexa à vencedora

O que fazer

Esperar o retry do supervisor, só isso

Pra prevenir, não duplique unidades por perfil sem necessidade e confira se existe alguma unidade por perfil instalada (o roteiro mais abaixo mostra como encaixar isso no diagnóstico)

Diferença entre –replace e –force no hermes gateway run

Resumindo: o --replace assume quem já atende o perfil, sem pular a checagem do hospedeiro, e o --force pula essa checagem e sobe um gateway separado

O que o –replace faz?

O hermes gateway run --replace assume o processo que atende aquele perfil, qualquer que seja o perfil que o lançou

Porém, diante do gateway próprio (standalone) de outro perfil, ele nunca age contra esse dono: quando o dono do host é o gateway standalone de outro perfil, ele nunca atende este perfil, então o --replace sobe ao lado dele, como um run comum, em vez de recusar e entrar em tempestade de reinícios

E ele não pula a checagem do HOSPEDEIRO (a trava, o host lock): é essa checagem, e não uma verificação de perfil, que só o --force pula

O que o –force faz?

O hermes gateway run --force inicia um gateway separado sem consultar o processo hospedeiro

A documentação trata isso como válvula de escape, pra quando o hospedeiro está travado ou respondendo errado

Também é o caminho para os dois casos de fronteira citados na própria documentação:

• frota dividida entre usuários UNIX distintos
• HERMES_HOME fora de <home padrão>/profiles/

Nesses casos, continua valendo: o gateway install (e também o gateway start) de um perfil nomeado recusa a rodar sem --force

Erro comum: usar –force pra calar o 75

Se liga nisso: o 75 "normal" é a unidade esperando a vez dela

Meter --force pra "resolver" esse ciclo cria um gateway paralelo que ignora o hospedeiro, e aí sim tu arruma problema de verdade. Se o 75 persistir por horas com a mensagem de hospedeiro repetindo no journal e nenhum processo gateway run de fato vivo, o caminho é investigar o bug #141567 citado acima, não forçar um segundo gateway

Roteiro de diagnóstico do gateway do Hermes Agent na VPS

A ideia é descobrir quem é o hospedeiro e quem roda por conta própria, e só depois decidir se mexe em algo

Se tu usa o template Docker da Hostinger, confirme primeiro em qual ambiente tu está executando os comandos abaixo: no host da VPS ou dentro do contêiner

1. Rode o status do perfil padrão:

hermes gateway status

Confira no resultado se o serviço do perfil padrão está ativo.

O erro comum aqui: rodar o comando no host achando que está dentro do contêiner (ou o contrário) e concluir que "não tem gateway nenhum"

2. Rode o status do perfil que está em ciclo:

hermes -p equipe gateway status

No exemplo, troque equipe pelo nome do perfil afetado. Comece pelo comando de status e pelo journal da unidade. O comando gateway run pode iniciar um gateway, então não o use como simples consulta.

Confira o journal da unidade e se existe algum processo gateway run ativo. O exemplo usa uma unidade de usuário chamada hermes-gateway.service. Ajuste o nome para o perfil em análise. Para uma unidade do sistema, consulte o journal do sistema.

journalctl --user -u hermes-gateway.service -n 100
pgrep -af 'gateway run'

Se aparecer a mensagem "A gateway already owns this host and has not published its served set yet" repetindo sem parar, junto com uma contagem de reinícios disparada e nenhum processo vivo, isso bate com o padrão relatado na issue #141567

3. Identifique qual perfil é o hospedeiro e confira duas coisas: se existe gateway.standalone: true no config.yaml do perfil e se há unidade por perfil instalada

Se o perfil estiver configurado com gateway.standalone: true, confira a seção sobre gateways independentes na documentação de gateways multi-perfil antes de alterar a unidade.

Compare essa configuração com a unidade em execução antes de agir.

4. Decida a ação:

• o status mostra aviso de perfil não atendido só esporadicamente e a unidade sai com 75 de vez em quando? Aguarde o retry, está tudo certo
• o journal mostra a mensagem "A gateway already owns this host and has not published its served set yet" repetindo por horas, com a contagem de reinícios disparada, e nenhum processo gateway run de fato vivo no servidor? Compare com o cenário da issue #141567 descrito acima antes de forçar qualquer coisa
• quer que o processo do teu perfil assuma quem atende ele hoje? Use --replace, sabendo que ele não age contra o gateway standalone de outro perfil
• hospedeiro travado, frota com usuários UNIX distintos ou HERMES_HOME fora de profiles/? Aí entra o --force

O erro comum aqui é o clássico: --force como primeira opção, só porque "funciona"

Para entender como a configuração distribui vários perfis, veja o guia sobre vários perfis num só gateway.

Hermes Agent em vídeo no canal

Curte aprender vendo? Tem vídeo do Hermes lá no canal, dá o play aí embaixo 🙂

Onde rodar o Hermes Agent com acesso root

O próximo passo é abrir a documentação vigente, conferir os comandos e aplicar o roteiro acima no teu servidor

Se você quer rodar o Hermes em um servidor separado, a VPS da Hostinger com o template do Hermes é uma opção (link de afiliado da Hostinger). Os comandos acima são para uma instalação em que o gateway roda como unidade do systemd. Se você usa o template em contêiner, confira o estado e os logs no gerenciador do contêiner.

Até o próximo post! 😀

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.