forked from Zakaria/hermes-agent
28 lines
1.2 KiB
Plaintext
Executable File
28 lines
1.2 KiB
Plaintext
Executable File
#!/command/with-contenv sh
|
|
# shellcheck shell=sh
|
|
# Main hermes service.
|
|
#
|
|
# IMPORTANT — this is NOT how the user's CMD runs.
|
|
#
|
|
# We chose Architecture B from the plan: the container's CMD (the bare
|
|
# command the user passes to `docker run <image> …`) runs as /init's
|
|
# "main program" via Docker's CMD mechanism, NOT as an s6-supervised
|
|
# service. This is the canonical s6-overlay pattern for "container
|
|
# exits when the program exits" semantics, and it lets us preserve
|
|
# every pre-s6 invocation contract (chat passthrough, sleep infinity,
|
|
# bash, --tui) without re-implementing argument routing through
|
|
# /run/s6/container_environment.
|
|
#
|
|
# So why does this service exist at all? Two reasons:
|
|
# 1. s6-rc requires at least one user service for the "user" bundle
|
|
# to be valid. We can't ship an empty bundle.
|
|
# 2. Future work may want to supervise a long-lived hermes process
|
|
# (e.g. for gateway-server containers); having the slot already
|
|
# wired in keeps that change small.
|
|
#
|
|
# For now this service is a no-op: it sleeps forever, doing nothing.
|
|
# The dashboard runs as a real s6 service alongside it (see
|
|
# ../dashboard/run) and per-profile gateways register dynamically via
|
|
# /run/service/ at runtime (Phase 4).
|
|
exec sleep infinity
|