git.stella-ops.org/docs/modules/scanner/operations/entrypoint-lang-supervisor.md

Entry-Point Runtime — Supervisors

Some containers intentionally launch multiple long-lived services (sidecars, appliance images, supervisord, s6, runit, pm2). Instead of forcing a single runtime classification, the detector can emit a Supervisor entry with child services enumerated separately.

Signals to gather

• Known supervisor binaries: supervisord, s6-svscan, s6-supervise, runsvdir, pm2-runtime, forego, foreman, overmind.
• Configuration files: /etc/supervisord.conf, /etc/s6/*.conf, Procfile, ecosystem.config.js.
• Multiple child processes that remain active after startup.
• Environment variables controlling supervisor behaviour (SUPERVISOR_*, PM2_HOME, S6_CMD_WAIT_FOR_SERVICES).

Implementation notes

• Keep the supervisor as the primary terminal but query configuration to list child commands.
• For each child, run the usual reduction + runtime detection and attach results as derived evidence.
• When configuration is templated (e.g., envsubst), evaluate ShellFlow output to resolve final commands.
• Record scheduling details (autorestart, process limits) relevant for incident response.

Evidence & scoring

• Supervisor detection flips LanguageType.Supervisor with mid-level confidence (0.6–0.7).
• Confidence increases when configuration explicitly lists services and child processes are observed (dynamic mode).
• Provide evidence for each child service ("manages: php-fpm on /run/php-fpm.sock", "manages: nginx listening on 0.0.0.0:80").

Edge cases

• Docker Compose-style images using bash to run multiple services should also map here if ShellFlow detects multiple & background jobs.
• Ensure we do not classify minimal init shims (tini, dumb-init) as supervisors—they should be collapsed.
• When supervisor manages only one child, collapse to the child runtime and drop the supervisor evidence to avoid noise.