Parar um perfil sem parar o gateway: parking no multiplexer

Correr muitos perfis tem um efeito colateral chato: por omissão há um só gateway anfitrião por máquina, o do perfil default, e é ele que serve todos. Até ao dia em que queres tirar um perfil do ar. hermes gateway stop para tudo, e reiniciar trinta perfis por causa de um que não precisas é desperdício, além de encher os chats com bots a piscar online e offline.

Desde a janela do v0.21.5 (tag v2026.9.24, de 24 de setembro) há uma via melhor: parcar um perfil. hermes -p <perfil> gateway stop desserve-o, parando os adapters das suas plataformas e tirando os jobs de cron dele dos ticks seguintes. Os outros perfis continuam a correr.

Como se usa

O ponto de partida é ver o que está a ser servido:

hermes gateway list

Nesta máquina dá vinte e seis perfis: ✓ default (current) e, por cada perfil servido, uma linha ✓ coder — served by the default multiplexer. Para o estado de um perfil em concreto:

hermes -p coder gateway status

Responde ✓ Gateway is running via the default-profile multiplexer e Manage it from the default profile: hermes gateway status. Com o multiplexer ligado, o ciclo de vida do perfil é gerido a partir do default.

Para parcar:

hermes -p coder gateway stop

Sai Profile 'coder' parked; its bots and cron are stopped. Start again with: hermes -p coder gateway start. A partir daí, hermes -p coder gateway status passa a dizer Profile 'coder': parked (hermes -p coder gateway start). Os outros perfis não notam nada.

Para o trazer de volta:

hermes -p coder gateway start

Se o host estiver vivo, volta a servir o perfil; se não estiver, o comando segue o caminho normal de arranque. Há ainda hermes -p coder gateway restart, que desserve e volta a servir sem deixar marcador, relendo a configuração. É o que queres depois de mexer no config.yaml desse perfil, e responde Profile 'coder' restarted by the host gateway.

O marcador é que manda

O estado de um perfil parco vive num ficheiro: ~/.hermes/profiles/<perfil>/gateway.parked, escrito antes do teardown. O conteúdo é ignorado, só interessa que exista. Três consequências práticas:

• Sobrevive a reinícios do host, portanto um perfil parco não volta sozinho depois de um reboot.
• O host re-varre a pasta profiles/ a cada trinta segundos, por isso criar ou apagar o marcador à mão tem o mesmo efeito que usar a CLI. Num script de manutenção, touch e rm chegam.
• Se o socket de controlo não confirmar o pedido, a CLI di-lo e o próximo rescan aplica o estado do marcador.

O perfil de lançamento é a excepção: o default não pode ser desservido, e um marcador lá é ignorado com aviso.

Também convém não ler o --all à letra. hermes gateway start --all e restart --all referem-se ao único multiplexer anfitrião, não a todos os gateways que estejam a correr na máquina. E nunca matam um perfil que ainda tenha gateway próprio: reportam-no e deixam-te hermes gateway migrate --multiplex.

E o gateway.multiplex_profiles está ligado por omissão, escrito como true no config.yaml do default. Pôr false está retirado: o gateway reescreve-o para true com um aviso, sem flip silencioso.

O que costuma correr mal

Parcar não é gateway.standalone: true. O standalone é um shim temporário de compatibilidade, não uma topologia suportada: o host nunca serve esse perfil, que corre o seu próprio gateway, e por isso nunca lhe escreve o marcador de parking. Parking é a via nativa do multiplexer e substitui o shim no que toca a parar e arrancar por perfil. No default é ignorado com aviso, porque o default é o host, e não há variável de ambiente para esta chave.

Sem --force, um perfil não arranca gateway próprio. install, start ou run recusam com exit 78 e Profile '<nome>' does not get a gateway of its own. A razão é boa: dois pollers no mesmo token ou na mesma porta. O --force é a saída para casos-limite, como uma frota dividida por utilizadores UNIX.

hermes gateway run com host vivo faz ATTACH. Não arranca um segundo processo: imprime o PID do host e os perfis servidos e sai com 0. Sob um supervisor de serviços sai com 75, para o systemd ou o launchd retentarem e a unidade retomar o controlo quando o host desaparece.

Parcar não interrompe trabalho já despachado. Um job que já arrancou num tick anterior acaba; o parking só impede os próximos. E não apaga o perfil, as sessões nem os jobs agendados.

No Dashboard e no Desktop a semântica é a mesma. Stop parca, Start desparca se houver host vivo, e /api/status lista os parked_profiles. Start num perfil que não está parco devolve 409. Um perfil standalone não é servido pelo multiplexer nem pelo hermes serve: os seus webhooks têm de apontar para o listener próprio, e o selector de destinos de cron ainda mostra bot-chat:<nome> mas o host não entrega lá.

E não se perde isolamento pelo caminho: cada turno encaminhado resolve a configuração, as skills, a memória, o SOUL e as chaves de provider do perfil de destino. As credenciais nunca são partilhadas entre perfis.

Vale a pena?

Se corres um perfil, isto não te diz nada. Se corres uma frota, é das melhores peças da janela: tirar um perfil de férias sem tocar nos outros, um ficheiro previsível a marcar o estado e um --all que finalmente quer dizer o que parece.