2026-06-06 — Hermes cron/gateway reliability under systemd supervision

핵심 요약

오늘의 1개 핵심 주제는 Hermes Agent의 cron·profile·gateway를 systemd 사용자 서비스 환경에서 안정적으로 운영하는 패턴이다.
Hermes 공식 문서 기준으로 cron은 /cron, hermes cron ..., 자연어, cronjob(...)로 관리되며, cron 실행 중에는 재귀적 cron 생성을 막는 안전장치가 있다.
다중 profile gateway는 Linux에서 profile별 ~/.config/systemd/user/hermes-gateway-<profile>.service로 분리되고, default profile은 hermes-gateway.service라는 별도 이름을 사용한다.
systemd 공식 문서 기준으로 장기 실행 서비스는 Type=exec가 execve() 실패를 더 잘 잡을 수 있고, crash 자동복구는 Restart=on-failure, RestartSec=..., StartLimitIntervalSec=..., StartLimitBurst=... 조합으로 다룬다.
운영상 핵심은 “무조건 재시작”이 아니라 관찰 가능성, start-limit, 수동 reset-failed 절차, self-restart 루프 방지까지 함께 설계하는 것이다.

Phillip 서버의 Hermes gateway/cron은 사용자가 자는 동안 보고서·모니터링·자동화 작업을 수행한다. 이때 OAuth/provider 오류, 네트워크 지연, profile별 env 누락, systemd transient 상태 때문에 “보내야 할 보고서가 안 감” 또는 “gateway가 죽었는데 모름” 문제가 생길 수 있다.
특히 profile이 늘어나면 각 profile의 .env, config.yaml, gateway service, log path가 분리되므로, default 하나만 확인해서는 전체 운영상태를 보장할 수 없다.
cron은 unattended 작업이므로 prompt 안에 delivery target, archive path, source rule, provider/model override 같은 운영 계약을 명시해야 재현 가능하고 장애 분석이 쉬워진다.

Hermes gateway 운영 점검 기본 순서:
1. hermes profile list로 profile 및 gateway 상태 확인
2. default는 hermes gateway status, named profile은 <alias> gateway status 또는 hermes -p <profile> gateway status
3. Linux user unit 확인: systemctl --user list-units 'hermes-gateway*'
4. 로그 확인: default ~/.hermes/logs/gateway.log, named profile ~/.hermes/profiles/<name>/logs/gateway.log
5. provider/auth 오류와 platform transport 오류를 분리해 진단
Hermes cron 운영 점검 기본 순서:
1. hermes cron list로 중복·구식 job 확인
2. unattended job은 schedule timezone, output path, source-link rule, failure behavior를 prompt에 넣기
3. OAuth 신뢰성이 낮은 job은 cron job 자체의 provider/model override 검토
4. workdir가 필요한 repo 작업은 명시하고, workdir job의 sequential 특성을 고려
다중 gateway wrapper가 필요하면 공식 문서의 hermes-gateways {start|stop|restart|status|list} 패턴을 적용하되, default profile은 hermes gateway ..., named profile은 hermes -p <profile> gateway ...로 분기한다.

Profile 분리 원칙: persistent memory, credentials, long-running gateway가 필요한 역할만 profile로 분리한다. 단순 리뷰어/구현자는 ephemeral delegate가 적합하다.
Service restart 원칙: gateway 서비스에는 자동 재시작을 두되, 짧은 시간 내 반복 실패는 start-limit로 멈추게 해서 log storm과 token-refresh storm을 막는다.
Transient 상태 처리: gateway restart 직후 activating (auto-restart) 또는 TEMPFAIL이 잠깐 보일 수 있다. 즉시 실패로 단정하지 말고 몇 초 후 profile list/status/log를 재확인한다.
Self-restart 금지 패턴: gateway 내부에서 자기 자신을 gateway restart/stop하도록 cron을 만들지 않는다. 외부 supervisor 또는 수동 ops 절차로만 gateway restart를 수행한다.
관찰성 우선: health check는 “process alive”만 보지 말고 최근 cron 실행 여부, outbound delivery 여부, provider auth error 여부를 함께 본다.

hermes-agent GitHub issue 검색 결과에 gateway가 자기 자신을 재시작하는 cron으로 respawn loop가 생길 수 있다는 사례가 있었으나, issue 내용은 공식 릴리스 문서가 아니므로 unverified로 취급한다. 다만 운영 가드레일로는 타당하다.
systemd unit file을 Hermes CLI가 생성하는 경우, 직접 unit을 수정하면 gateway install 재실행 시 덮어쓰기될 수 있다. 변경 전 unit path와 생성 방식을 확인해야 한다.
user service는 SSH logout 후에도 유지되려면 환경에 따라 linger가 필요할 수 있다. 서버별로 loginctl show-user 또는 실제 logout 테스트가 필요하다.
cron provider fallback은 일반 gateway turn의 fallback과 다르게 동작할 수 있으므로, 중요한 job은 job-level provider/model을 명시하는 것이 안전하다.

Hermes cron job의 실제 저장 포맷과 provider/model override 필드는 현재 설치 버전에서 어디에 저장되는가?
hermes gateway install이 생성하는 Linux systemd unit의 기본 Restart, RestartSec, env loading 방식은 무엇인가?
Phillip 서버에서 profile별 gateway/cron delivery를 한 번에 점검하는 read-only health script를 만들 수 있는가?
Mattermost/Telegram 등 platform별로 “transport OK but provider auth broken”을 자동 분류하는 로그 패턴은 무엇인가?