Haiku launch_daemon: Jobs, Services, Ports, and Dependency-Based Startup
A systems-level explanation of Haiku launch_daemon jobs and services, demand activation, dependencies, readiness, configuration, and diagnosis.
After Haiku’s kernel finishes its early work, launch_daemon becomes the first userland process and coordinates the services and jobs that form the running system. Thinking of it as a list of boot scripts misses its central idea: named resources and dependencies allow components to start when their prerequisites exist, including activation on demand.
Jobs and services describe different contracts
A job is an executable unit with arguments, environment, launch conditions, and restart behavior. A service is a named facility that clients can request. A service may publish a port and arrange for its provider job to launch when the first client tries to connect. This lets the dependency graph express intent without every consumer hard-coding a process order or polling for a PID.
The distinction also clarifies failure. “The process exists” does not necessarily mean “the service is ready.” A provider may need to initialize state and publish its port before dependents can make progress. Conversely, a job can complete successfully without being a long-running service. Troubleshooting begins by identifying which contract the configuration promises.
System and packaged configurations are data consumed by the daemon, not shell fragments to edit casually. Inspect the installed configuration that corresponds to the running package and release. Package activation can replace files or expose a different version after an update, so preserve the original and compare rather than modifying system-owned data in place.
Dependency startup is not arbitrary ordering
A dependency names a resource that must become available. The daemon can start providers and wait for the graph to resolve. Cycles cannot become ready: if job A waits for B while B waits for A, changing a numeric delay merely hides the modeling error. Optional dependencies and conditions should be represented as such instead of simulated with unconditional sleeps.
Demand activation reduces unnecessary boot work, but clients must still handle service failure and timeouts. The fact that a port request can trigger a launch does not guarantee that the program will remain healthy, accept the message, or return a valid result.
Haiku’s launch_roster command exposes administrative operations such as listing, starting, and stopping launch-managed entries. Use it to observe the daemon’s view before killing processes manually:
launch_roster list
launch_roster start user:MyService
launch_roster stop user:MyServiceNames and available subcommands depend on the installed build, so consult launch_roster --help and copy the exact identifier reported by list. Do not experiment on foundational system services from an active desktop session.
Restart policy is part of correctness
Automatic restart is valuable for a transient crash and dangerous for a deterministic configuration error. A job that exits instantly can consume CPU, flood logs, and repeatedly mutate data. Configure restart conditions narrowly, ensure clean termination is distinguishable from failure, and provide backoff or a failure ceiling where the format supports it.
The executable should use absolute or package-correct paths, define its required environment, and avoid assuming an interactive shell profile. Services start in a controlled system context; a program that works only after a Terminal has modified PATH is not correctly described.
Diagnose the graph, not only the crashed process
When a service is missing, record the exact name, inspect the roster, examine system logs, verify the provider executable and package state, and trace each declared dependency. If the provider starts but never publishes readiness, debug initialization and permissions. If it is never selected, check the condition, configuration location, and service name. If it loops, capture the first failure before later retries obscure it.
launch_daemon makes startup more declarative, but it cannot repair an incoherent graph. Reliable configurations accurately describe ownership, prerequisites, readiness, failure, and lifecycle; reliable clients still tolerate the service being unavailable.
Related:
- How to Build Resizable Haiku Interfaces with BLayout Instead of Fixed Coordinates
- Fixing a Haiku launch_daemon Job That Repeatedly Restarts or Never Becomes Ready
Sources: