A sidecar already gets a port and nothing here changes that: it binds 0, the
kernel picks, it announces the number. That is right for what it is - a private
detail between two processes, loopback, re-chosen every restart, and nothing
outside Officer needs it.
A port something ELSE connects to is a different thing. A plugin serving a
website has to be reachable from nginx, which means the number must survive a
restart and be knowable by whoever writes the proxy configuration. Ephemeral
fails both, which is why the first site plugin was going to hardcode 3011 and
hope.
So: `extraPorts: [{ name: 'site', preferred: 3011 }]` in a manifest, allocated at
install, persisted in plugin_ports, and delivered as PORT_SITE in the sidecar's
pm2 environment. Environment rather than the registration socket because a socket
answer arrives after the process has already had to decide what to bind, and pm2
is the only thing that can tell a process something before it starts.
What the platform guarantees is the part per-plugin config could never do: no two
plugins are ever handed the same number. That is a unique index rather than a
convention, because a collision is not a duplicate row - it is two services
fighting over a listener where the loser fails to bind and the winner is whoever
started first.
`preferred` is a wish, not a claim. A plugin usually arrives after the thing that
connects to it, and moving that configuration is work the platform can spare
somebody; but a preference that could fail an install would be a claim wearing a
softer word.
Allocations survive uninstall and are released only by purge. The number is
written down where this database cannot see it, so handing it to a different
plugin because this one was briefly removed points that configuration at the
wrong service.
Pm2App gained `env`, emitted as JSON rather than hand-quoted: a port is a number
today, but this is the seam where a path arrives eventually, and one apostrophe
in a value produces a file PM2 cannot parse - which takes every process on the
machine down, not just the plugin's.
Verified: stable across calls, distinct across plugins, released cleanly,
honours a preference, and a plugin declaring no ports gets no env key at all.
`OFFICER_DISABLED_SIDECARS` in .env, comma separated, filtered out of the
generated ecosystem file.
core processes are a fixed array because the platform's own features depend on
them. that is still true — what is not true is that every host runs every
feature. fofos is a 1.9 GB machine serving a website, and officer-opencode sat on
it costing 456 MB for a harness nobody there uses.
it froze hard twice today, and the tell is what is MISSING from the journal: no
OOM kill, no panic, no shutdown — the log simply stops mid-session and resumes at
the manual reboot. that is memory exhaustion with no headroom left to kill
anything cleanly, on a box with 1.9 GB and a 2 GB swapfile that was already 440
MB into swap one minute after boot.
.env rather than a database setting, and that is the load-bearing part: this file
is regenerated during a plugin install, so a host that dropped a process needs it
to stay dropped across one. per-host is also exactly the scope of the decision.
not validated. naming `officer` or `officer-pty` will break that host, and which
processes are safe to drop depends on what the host is for — which this script
cannot know and should not guess.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
bun gen:ecosystem writes the whole file from three sources: CORE_PROCESSES read
directly out of scripts/setup/officer-setup/lib/services.sh (shelled out to bash,
so there is exactly one list rather than a TS copy to keep in sync by hand),
marketplace plugins that are installed AND enabled in Postgres and actually ship a
sidecar/, and app-store services that are installed AND enabled, using each
catalogue entry's `process` name against the src/servers/sidecar/<id>/index.ts
convention.
Extracted `pluginPm2Entry` (a pure DiscoveredPlugin -> Pm2App) out of
addPluginToEcosystem so the live install/uninstall path and this from-scratch
rebuild share one definition of what a plugin's entry looks like, rather than two
that can drift apart. addPluginToEcosystem's own behavior is unchanged.
Complements, not replaces, the existing incremental add/remove in
servers/plugins/ecosystem.ts — that edits the live file at install time; this
regenerates the whole thing, for a fresh clone, drift, or restoring from a backup.
Found while testing against this machine's real file, worth flagging rather than
silently working around: officer-marketplace (the marketplace.officer.dev process,
src/servers/marketplace/server.tsx) is in this machine's ecosystem.config.cjs by
hand and is modeled by neither the plugin system nor the app-store catalogue, so
this script does not know about it and would drop its entry on a real run. Left
alone rather than guessed at.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
pastilhas
