On this page
Operator manual

app:worker

Run one unit of the paired worker deployment as its container's PID 1. Control supervises the outbox relay, scheduler poller, independent autoscaler and media coordination. Execution runs resident ordinary async consumers, one separate scheduler consumer and the native execution daemon. Native probes, encoders, CPU helpers and scheduled console children run in execution. The host bin/worker-deployment.php supplies the options from a version 5 manifest; see Worker deployment.

Quick start

The host deployment controller constructs this command and runs it as PID 1 in each admitted worker container. Do not launch it with dc exec or as an additional web-container process. Use the host manifest reference to provision the pair, and Background work for start, stop, replacement and uncertain outcomes.

Options

Option Default Description
--deployment BAANDER_WORKER_NAMESPACE Deployment namespace
--boot-id BAANDER_WORKER_BOOT_ID Fresh 32-character hexadecimal boot identity
--unit BAANDER_WORKER_UNIT Required unit identity: control or execution
--memory-mib — Required unit ceiling: at least 2944 MiB for control or 4160 + 320 * (maximumConcurrency - 1) MiB plus the scheduled console reservation for execution
--pids-limit — Required unit PID capacity: at least 129 for control or 256 + maximumConcurrency - 1 for execution; at most 4096
--scheduled-console-mib 0 Execution reservation for one synchronous scheduled console child; 0 disables it, otherwise at least 320 MiB; control requires 0
--autoscaling-profile — Required complete JSON profile from the version 5 manifest; all fields bind both unit recipes
--lock-dir /tmp/baander-worker-locks Private unit lock directory
--ipc-dir /run/baander-worker Private IPC directory shared by the pair

Details

When the environment sets BAANDER_WORKER_NAMESPACE, BAANDER_WORKER_BOOT_ID or BAANDER_WORKER_UNIT, the matching option must be absent or equal to it. Memory values are whole MiB up to 1048576. The host manifest binds these admission values to separate Docker memory, CPU and PID ceilings and disjoint CPU sets. They do not certify measured usage or capacity.

Execution starts consumer-0 through consumer-(maximumConcurrency - 1) for async, plus one separate scheduler consumer. Every ordinary slot remains resident and fully reserved, including when parked. Parking gates the next receive without reclaiming RSS or interrupting handling, acknowledgment, retry publication or keepalive. A shrink waits for occupied permits to drain below the target before admitting more work. Control's independent private autoscaler collects queue and execution cgroup evidence and updates admission through boot/epoch-fenced IPC; it does not consume ordinary work. It reserves 320 MiB within control's ceiling.

The manifest reference defines profile bounds and the measured maximum-two example and its workload limits. Missing measurements prevent growth and reduce ordinary admission to at most one. Severe memory/PID pressure closes admission; recovery needs fresh samples. Status exposes slot counts, decision reason and freshness without treating missing consumers as idle.

Container compilation checks default routes, handlers registered for the transport, payload codecs, JSON serialization and bounded retry policies. Producer dispatch checks the actual selected senders, including explicit transport stamps. Catalog resource classes describe work; the unit budgets above remain the admission policy. PHP kernel processes use a 256 MiB heap ceiling; unit memory also reserves native and management headroom.

The supervisor checks REDIS_URL and MESSENGER_TRANSPORT_DSN before launching children. Accepted forms preserve the configured streams and baander group; consumer overrides are rejected. Each admitted consumer receives an identity derived from the deployment, boot, worker role and launch generation, replacing an inherited MESSENGER_CONSUMER_NAME. See Messenger configuration for URL forms. Invalid configuration exits without child launch, and errors omit credential-bearing values. The host deployment controller applies the same URL checks before container creation.

Control owns the deployment lease; execution observes it. Both units require matching boot/epoch peer evidence before business admission. Background work defines peer failure and the 35-second drain deadline; the worker pair has a 30-second startup admission deadline. A worker_supervisor_stopped log entry is neither a readiness result nor a containment receipt.

The media coordinator admits at most three video jobs and one audio rendition. Each job uses a fresh kernel in control and sends bounded native requests over the private Unix socket to execution. Hardware probing, FFmpeg, video CPU helpers and scheduled console children belong to execution; no devices are admitted. Native requests carry deployment, boot, epoch, client generation and attempt identity. Uncertain completion retains ownership until containment or a confirmed release; caller cancellation alone does not free a native slot. Encoder and file I/O threads count against execution's PID ceiling.

The supervisor does not restart itself. Reconcile a failed deployment through the host controller before replacing it; see the lifecycle procedure linked above.

Exit codes

Code Meaning
0 The deployment drained after a stop signal
1 A child or the lease failed, the drain timed out, or the supervisor could not start; error output omits diagnostics that could contain secrets
2 An option is missing or invalid, it differs from the container's deployment, boot or unit identity, or worker transport configuration is invalid