Fixing Tracker Crashes and Hangs on Haiku

Tracker — Haiku’s desktop and file manager — is, architecturally, an ordinary application built on the same Looper/Handler pattern every other Haiku application uses, not a privileged system process. That matters directly for how you recover when it crashes or stops responding.

Step 1: confirm whether Tracker specifically has hung, versus the whole system

Try opening the Deskbar menu, or moving the mouse cursor —
if the cursor still moves and other running applications
remain responsive, it's specifically Tracker that's stuck,
not a full system hang.

Step 2: restart Tracker without rebooting

Open a Terminal (if still accessible), then:
kill -9 $(pgrep Tracker)
/boot/system/Tracker &

Because Tracker is an ordinary application process, killing and relaunching it recovers the desktop without needing to restart the entire system — a direct, practical consequence of Haiku’s pervasively multithreaded, process-per-application architecture.

Step 3: if Terminal isn’t reachable either, use a virtual terminal switch

Haiku supports switching to a different workspace or,
in some configurations, a text console, to reach a
working shell even if the graphical desktop is
unresponsive.

Step 4: check for a specific folder or file triggering the crash

If Tracker crashes repeatedly right after restarting,
note whether it happens immediately (likely tied to
restoring a specific previously-open window/folder)
or only when navigating to a specific location.

Tracker restores previously-open windows on restart by default — a specific corrupted folder or an unusual file triggering a rendering bug can cause a crash loop tied to that restoration, rather than a general Tracker problem.

Step 5: clear Tracker’s saved window state, if a crash loop is tied to window restoration

Locate and rename or remove Tracker's settings file
(location varies by Haiku version) to prevent it from
attempting to restore the specific window state that
may be triggering the crash.

Step 6: check available memory and disk space

A generally resource-starved system can manifest as
application instability broadly, not specifically a
Tracker bug — confirm the system isn't critically low
on RAM or disk space before assuming this is a Tracker-specific issue.

Step 7: check for a known bug matching your specific crash, if it recurs consistently

Since Tracker is actively maintained open-source software, a specific, reproducible crash (especially one tied to a specific folder structure, file type, or action) is worth checking against Haiku’s bug tracker — you may be hitting an already-known, already-fixed-in-a-newer-build issue.

Step 8: report a reproducible crash, if it isn’t already known

Include: exact steps to reproduce, Haiku version, and
any crash log Haiku's debugger produces automatically
when an application crashes.

Haiku’s debug system typically generates a report automatically when an application crashes — attaching this to a bug report gives maintainers direct diagnostic information rather than a vague description alone.

Why treating Tracker as “just another application” is the right mental model

Coming from an operating system where the desktop shell is a deeply privileged, hard-to-restart system component, it’s easy to assume a crashed Tracker means trouble on the same scale — but Haiku’s architecture treats Tracker as an ordinary application process like any other, which is exactly why restarting it (Step 2) is normally sufficient, fast, and low-risk, rather than requiring a full system reboot the way recovering a crashed shell might on a system where the desktop environment runs with special, harder-to-restart privileges.