Startup lifecycle¶

DUMB distinguishes a service that is still starting from one that is unhealthy in steady state. The lifecycle is:

1. initializing
2. preinstalling
3. starting_services
4. stabilizing
5. ready or degraded
6. shutting_down

The DUMB API starts before enabled-service preinstall. An already-installed frontend can also start early, so the dashboard can show startup progress while large service installs or migrations continue.

Readiness and stabilization¶

During stabilizing, DUMB checks every enabled process and each configured port, frontend_port, backend_port, and webdav_port. Every enabled service must remain ready for the stabilization window before the lifecycle becomes ready.

"dumb": {
  "startup": {
    "readiness_timeout_seconds": 300,
    "readiness_poll_interval_seconds": 5,
    "stabilization_seconds": 15
  }
}

If the deadline expires, DUMB enters degraded instead of shutting down the API/frontend. The dashboard identifies services that missed readiness, and one consolidated degraded-startup notification can be routed to operators.

Startup-safe monitoring¶

Until startup reaches ready or degraded:

• Auto-restart does not health-check or restart services.
• Automatic service, resource, database, and recovery notifications are suppressed.
• Database Health does not probe a service that is still starting.
• Manual notification tests remain available.
• Docker health reports startup progress instead of declaring the container unhealthy merely because a slow service is still initializing.

When startup becomes terminal, notification monitoring records a fresh baseline. It does not send recovery messages for failures that existed only during startup. Persistent conditions must still satisfy their normal duration threshold before they alert.

Auto-restart then applies its grace period. A successful process spawn is only an attempt; DUMB records service.auto_restart.succeeded after the restarted service passes health checks.

Preinstall behavior¶

Every enabled instance is preinstalled. Instances of the same service key run sequentially so shared source/runtime trees are not modified concurrently, while different service keys can still preinstall in parallel.

A failed preinstall is retried through normal service startup. Startup is reported as degraded only if the service still misses the final readiness deadline.

Ownership and network storage¶

Startup ownership repair no longer performs a full count pass followed by a second walk. It caps ownership workers and treats correctly owned top-level trees as healthy, avoiding repeated traversal of large package caches on NFS. Service-specific setup still repairs a subtree when its top-level ownership is wrong.

JavaScript package caches are disposable. For NFS-backed /config, consider moving these existing cache roots to host-local storage with the matching environment overrides:

• DUMB_PNPM_STORE_ROOT
• DUMB_BUN_CACHE_ROOT
• DUMB_YARN_CACHE_ROOT

Keep durable service configuration and databases on storage appropriate for their recovery requirements.

API¶

When capability startup_lifecycle is true:

GET /api/process/startup-status

The response includes the current phase, timestamps, expected services, per-service pending/starting/ready state, and terminal failures.