# 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.