Skip to content

Processes

The daemon dispatches the routes declared in its schema, the app owns the client lifecycle, and the CLI dispatches user commands into those capabilities. The entry points below trace those boundaries. crates/agentd/src/routes.rs:36 crates/microvms-app/src/sandbox.rs:1113 crates/microvms-cli/src/main.rs:216

Entry point: crates/microvms-app/src/sandbox.rs:948

  1. Sandbox::ensure_image prepares the request and artifact on a blocking worker before obtaining build services or resolving the caller’s account. crates/microvms-app/src/sandbox.rs:960
  2. The ensure loop describes the content-addressed image and selects reuse, wait, delete, await deletion, or build from its state and the force flag. crates/microvms-app/src/control/ensure.rs:754
  3. A ready image can return immediately; a running build is awaited, while a failed image or a forced ready image is removed before replacement. crates/microvms-app/src/control/ensure.rs:760
  4. When the name is available, the artifact is uploaded once and create_image sends the request after its local preflight. crates/microvms-app/src/control/ensure.rs:802 crates/microvms-app/src/control/image.rs:188
  5. wait_for_image polls until ready, failed, or timed out; after the stall grace it probes the build list once for a pending-only build. crates/microvms-app/src/control/image.rs:405
  6. A refused create can join the image that won a concurrent create; a successful local build retains its logging configuration in the returned image. crates/microvms-app/src/control/ensure.rs:809
  7. The sandbox retains the resulting image for later launch and teardown; the direct build_image path creates and waits without the ensure loop. crates/microvms-app/src/sandbox.rs:982 crates/microvms-app/src/sandbox.rs:924

Entry point: crates/microvms-app/src/sandbox.rs:1113

  1. Sandbox::run refuses a detached or previously launched handle, evaluates the requested network posture, and selects an explicit or previously built image. crates/microvms-app/src/sandbox.rs:1132
  2. It prepares the launch token and optional tunnel identity, builds the run-hook payload, and copies the requested lifecycle settings into the wire request. crates/microvms-app/src/sandbox.rs:1172
  3. The control plane checks launch connectors, resolves an image name to its ARN when needed, and sends RunMicrovm. crates/microvms-app/src/sandbox.rs:1224
  4. An accepted launch records Pending, the image’s existence, the launch windows, and the returned VM; a non-waiting call builds a session and returns at this point. crates/microvms-app/src/sandbox.rs:1261
  5. A waiting call enters wait_until_running, using the launch-adoption wait when a caller-supplied client token can refer to an existing VM. crates/microvms-app/src/sandbox.rs:1328
  6. After the service reports running, the sandbox records bootstrap completion, constructs the session if needed, and polls daemon readiness before returning it. crates/microvms-app/src/sandbox.rs:1343

Entry point: crates/microvms-app/src/sandbox.rs:1635

  1. suspend requires a running, attached VM before sending the suspension request. crates/microvms-app/src/sandbox.rs:1636
  2. Once the request succeeds, it records Suspending, then waits for SUSPENDED or TERMINATED. crates/microvms-app/src/sandbox.rs:1655
  3. The returned state updates the local lifecycle, including the terminal marker when the VM terminated during suspension. crates/microvms-app/src/sandbox.rs:1671
  4. resume rejects a terminated VM before any call. When the handle still holds Running, it first reads the VM’s state with GetMicrovm, because the service can suspend an idle VM without a client call. A VM the service reports as ended records the sandbox Terminated and fails with WindowClosed. Then resume rejects any state other than suspended. It doesn’t check the time spent suspended; the service decides. crates/microvms-app/src/sandbox.rs:1725 crates/microvms-app/src/sandbox.rs:1735-1766 crates/microvms-app/src/sandbox.rs:1767
  5. It sends the resume request and waits for RUNNING, treating dead states as failures. crates/microvms-app/src/sandbox.rs:1779 crates/microvms-app/src/sandbox.rs:1793
  6. The running response updates the VM record and rebinds the session to its endpoint. A resume the service refuses for a VM that ended records the sandbox Terminated. crates/microvms-app/src/sandbox.rs:1801 crates/microvms-app/src/sandbox.rs:1782

Entry point: crates/microvms-app/src/sandbox.rs:1827

  1. terminate returns a report even when the handle is detached; otherwise it marks teardown and releases the session. crates/microvms-app/src/sandbox.rs:1828
  2. For a known VM, it records termination intent before calling the control plane, then records acceptance or the failure and undeleted identifier. crates/microvms-app/src/sandbox.rs:1843
  3. If requested and the termination was accepted, it waits for TERMINATED; a wait failure remains in the report. crates/microvms-app/src/sandbox.rs:1858
  4. Optional image deletion retries through the control plane and records whether deletion succeeded. crates/microvms-app/src/sandbox.rs:1883
  5. Each image deletion attempt lists all version pages before removing extra versions, deleting the image, and checking its response state. crates/microvms-app/src/control/image.rs:1247
  6. Optional build-log-group cleanup is reported last as undeleted because this path does not remove CloudWatch Logs groups. The returned report includes the final local lifecycle. crates/microvms-app/src/sandbox.rs:1905

Entry point: crates/agentd/src/routes.rs:222

  1. Route assembly maps each platform hook to its handler; the run handler records the invocation before parsing its envelope and nested payload. crates/agentd/src/routes.rs:151 crates/agentd/src/routes.rs:230
  2. The run handler prepares optional tunnel identity material and calls bootstrap_with_identity to install the launch state. crates/agentd/src/routes.rs:267
  3. On the first accepted bootstrap, it runs configured per-VM identity repair on a blocking worker and invokes the workload’s run handler before returning success. crates/agentd/src/routes.rs:278
  4. An identical replay succeeds without running initialization again; a conflicting bootstrap returns a conflict. crates/agentd/src/routes.rs:304
  5. The suspend, resume, and terminate routes record their invocation and await handler processing before acknowledging the hook. crates/agentd/src/routes.rs:343 crates/agentd/src/routes.rs:370 crates/agentd/src/routes.rs:388
  6. For an invocation retained in the hook log, hook_handlers::run looks up a configured handler, serializes execution, and records its outcome; handler failure does not fail the platform hook. crates/agentd/src/hook_handlers.rs:57

Entry point: crates/agentd/src/exec.rs:341

  1. start parses the request, checks its identifier and timeout, and resolves the command’s execution plan. crates/agentd/src/exec.rs:345
  2. build_command combines the plan’s environment layers, optional working directory and user settings, process group, and requested pipes. crates/agentd/src/exec.rs:1216
  3. A known execution identifier returns success; a new one enters spawn, which starts the child, captures its process group and pipes, and registers the execution. crates/agentd/src/exec.rs:391 crates/agentd/src/exec.rs:1312
  4. The detached waiter concurrently observes child exit and drains stdout and stderr; a timeout signals the process group and waits for the child. crates/agentd/src/exec.rs:1361 crates/agentd/src/exec.rs:1464
  5. Requested group reaping runs after direct-child exit; the waiter then continues draining inherited output pipes until EOF or the linger deadline. crates/agentd/src/exec.rs:1491
  6. Completion stores the terminal marker and result, closes the daemon’s stdin handle, and broadcasts the finished event. crates/agentd/src/exec.rs:1383

Entry point: crates/agentd/src/exec.rs:487

  1. stream parses the requested offset, finds the execution, and attaches to its shared output. crates/agentd/src/exec.rs:492
  2. Shared::attach subscribes to live frames and snapshots retained output under the output-log lock, returning any gap and the replay cursor. crates/agentd/src/exec.rs:303
  3. The handler reads the terminal marker after the snapshot and constructs an SSE response with keepalives. crates/agentd/src/exec.rs:505
  4. The stream trims output already delivered and emits gap events for missing byte ranges; its terminal event reads the retained completion marker. crates/agentd/src/exec.rs:547 crates/agentd/src/exec.rs:567
  5. The client’s stream state machine advances its cursor across delivered output and gaps, and stops after an exit event. crates/microvms-app/src/session/exec.rs:650
  6. A retryable failure or body end without an exit event can reconnect with bounded backoff from that cursor; each attach builds fresh request headers. crates/microvms-app/src/session/exec.rs:605 crates/microvms-app/src/session/exec.rs:704 crates/microvms-app/src/session/exec.rs:726

Entry point: crates/agentd/src/fs.rs:1473

  1. write_tar parses the target path, requires an absolute extraction root, and reads the configured archive limits. crates/agentd/src/fs.rs:1474
  2. It checks the root filesystem’s available capacity before spooling the request body through the disk guard. crates/agentd/src/fs.rs:1494
  3. A successfully spooled archive is handed to a blocking worker for extraction. crates/agentd/src/fs.rs:1519
  4. The extractor opens the confined root and disables ownership, permission, and extended-attribute restoration from the archive. crates/agentd/src/fs.rs:684
  5. Each member is checked against the archive limits and destination rules before its data is written through the confined filesystem access. crates/agentd/src/fs.rs:712 crates/agentd/src/fs.rs:844
  6. The extractor checks capacity as data lands, applies deferred modes after extraction, and returns a success or refusal through the route. crates/agentd/src/fs.rs:864 crates/agentd/src/fs.rs:1524

These pages cite many of the same source files as this one.