Skip to content
Haiku OSFix Published Updated 3 min readViews unavailable

Fixing a Haiku launch_daemon Job That Repeatedly Restarts or Never Becomes Ready

A recovery-first method for Haiku launch_daemon loops: preserve first-failure evidence, inspect the roster and graph, isolate overrides, and verify readiness.

A launch-managed job that exits immediately can be restarted so quickly that later log noise hides the original error. A different failure looks similar: the process remains alive but never publishes the service or port its dependents require. The repair is to preserve the first failure, identify the exact job and configuration owner, then test the dependency and readiness contract—not to keep killing the PID.

Stabilize without disabling the whole system

Record the affected service name, visible symptom, last known change, package update, and whether the failure is system-wide or limited to one user session. Save relevant system-log entries before repeated restarts rotate or flood them. If the system remains usable, do not reboot reflexively; the running state contains the best evidence.

List the roster and copy the precise identifier:

launch_roster list
launch_roster --help

Use the installed help because names and administrative details can change. If the roster supports stopping the nonessential affected entry, stop that exact job while investigating. Never broadly stop foundational services on the live desktop. For a boot-blocking third-party component, use Haiku’s Boot Loader safe-mode and package-state options to reach a recoverable configuration.

Find the authoritative configuration

Determine whether the entry comes from the base system, an installed package, or a user override. Query package ownership and compare the active file with the packaged version. Do not edit generated or package-owned system data in place: the next activation may replace it, and an undocumented local edit makes the failure irreproducible.

Look for these common deterministic causes:

  • an executable path that no longer exists after an update;
  • a binary for the wrong architecture or a missing shared library;
  • a required settings directory or data file with wrong ownership;
  • an environment assumption inherited from an interactive Terminal but absent at launch;
  • a dependency name that no provider publishes;
  • a cycle in which two services each wait for the other;
  • a port or service name that the process fails to publish;
  • a restart rule that treats a clean one-shot completion as failure.

Validate the executable independently only when it has a documented safe diagnostic mode. Starting a service binary manually can create two competing instances or bypass the environment that reproduces the bug. Prefer inspecting linked libraries, configuration, and the original exit status first.

Distinguish crash, clean exit, and missing readiness

A crash should leave an error or debugger evidence. A clean exit may mean the job is actually one-shot or rejected its configuration. A long-running PID with unavailable clients points toward readiness: confirm whether it created the expected port or registered the named service and whether its own initialization is blocked on another resource.

Trace the dependency graph outward one edge at a time. A provider can be healthy while a dependent asks for a misspelled resource. Adding a sleep may change timing, but it cannot repair a nonexistent provider or cyclic graph.

Apply one reversible correction

Restore the packaged configuration, remove or rename a stale user override, reinstall the owning package, correct the documented path, or update the third-party package as the evidence requires. Keep the original file and record its checksum. If a configuration format is undocumented, do not invent keys based on another service’s file.

Start the exact entry through the roster and observe from its first attempt. Verify more than process survival: the expected service becomes available, a real client completes an operation, dependencies settle, log volume returns to normal, and the job remains stable through logout or reboot when appropriate.

If restoration of the known-good package state fixes the loop, compare old and new data offline and report the minimal reproducer upstream. That turns a frantic restart problem into a traceable configuration, packaging, or program defect.

Related:

Sources:

Comments