Recognising — and clearing out — packaged sidecars whose window is gone.

The Tauri shell is the only thing that ever spawns a packaged sidecar. A sidecar whose shell is gone has definitively lost its window: nothing will heartbeat it again, nothing will SIGTERM it on quit, and it keeps every process its supervision tree owns running until the machine reboots.

Which process is the shell takes some care. Generated shells say so, in EX_TAURI_SHELL_PID, and that answer is used whenever it is there — see shell_pid/0. Without it the shell is read off the process tree. Burrito's launcher (1.6, which ex_tauri requires) spawns the BEAM as its child and waits on it, so a packaged BEAM's parent is the launcher and the shell is one level further up; a release script or the dev shim execs the VM, so there the parent is the shell itself. A launcher is recognised by its executable being named after the release, which is what Tauri names the bundled sidecar.

That is not hypothetical. It has now been observed in two ex_tauri apps on one machine: seven sidecars of one running at once, the oldest holding its HTTP port for three and a half days so that every later launch died on :eaddrinuse; and four of another, two days old, whose only remaining trace was the ps output — their unpack directories had already been replaced.

Three parts to the answer:

• reclaim_port/2 takes the port back from an orphan before your endpoint tries to bind it, so a stale sidecar can no longer lock the user out;
• reap_orphans/1 stops the rest, which hold no port but go on running timers, pollers and child processes with no window to show them in;
• orphan?/0 lets a running sidecar notice that its own shell is gone, which is the case a heartbeat cannot see — a heartbeat that never arrived is indistinguishable from a slow boot, and ExTauri.ShutdownManager uses this as its fourth stop signal.

Whose sidecar is it

Burrito names the unpack directory after the release, and mix ex_tauri.install scaffolded that release as :desktop for everyone until it started deriving the name from the application. Every app installed before that shares one directory: two of them both unpack to .burrito/desktop_erts-<vsn>_<app vsn>/, and every predicate that answers on the path alone answers the same for both. That is not a hypothetical — it is how four sidecars of one app were read as abandoned instances of another, one blind sweep away from being SIGTERMed by a program that did not own them.

A unique release name is the real fix and new installs get one, but this check has to hold regardless: the machine an app runs on is not the machine it was installed on, and the orphan it finds may well predate the rename.

identify/2 is what separates them: the release name cannot, but the payload can, because Burrito unpacks each application into lib/<app>-<vsn>. It has three answers rather than two, since the unpack directory of a running sidecar can be deleted out from under it — an upgrade that cleans up after itself leaves the old version running from a path that no longer exists, which is precisely the long-lived orphan this module exists for. "Cannot tell" has to stay distinguishable from "not ours", and the two callers weigh it differently:

• reclaim_port/2 evicts on :unknown. The port is yours by configuration, so a parentless Burrito sidecar squatting it is an old copy of you whichever way its directory went.
• reap_orphans/1 requires :ours. It sweeps the whole machine on nothing but a path shape, and leaking one of your own orphans is a far smaller harm than killing someone else's running app.

Options

Both entry points take:

• :otp_app — the application Burrito unpacked, used to recognise your own payload. Defaults to the sanitised :app_name, which is already what most apps are called ("Codrift" -> :codrift).
• :release_name — the release Burrito wrapped. Defaults to "desktop", what mix ex_tauri.install generates.

Unix only. On Windows every predicate answers "not an orphan", which degrades to doing nothing rather than guessing.