open actions create zombie xdg-open processes

[AnthonyZhOon]

Open¹ actions do not perform wait() and directly use std.process.Child.spawn() to create the subprocess. This results in zombie xdg-open processes that are not reaped until the parent ghostty process exits and the init command takes ownership and perform child reaping.

Environment

• Fedora Linux 41 (systemd), hyprland
• Built ghostty off tip

Reproduction

• Launch ghostty
• Perform Open Configuration (keybind or context menu)
• Close the opened configuration editing program
• A zombie xdg-open process is left as a child of the running ghostty process
  zombie.webm²

Potential solutions

The double-fork method, intially create a spawner, which immediately spawns the subprocess xdg-open, the spawner immediately exits after, returning responsiveness to the ghostty thread. When the grandchild xdg-open exits, after its direct-parent has exited, its parent becomes the nearest ancestor child-reaper³, usually init which should reap it. As a result, we unconditionally wait on the short-lived spawner process instead.

Note:
I tried simply adding a .wait() on the xdg-open process in open.zig¹ but this did not result in ghostty being responsive.
It appears xdg-open waits for its children before itself exiting.

There's other solutions listed at this stackoverflow.

I was concerned when a zombie xdg-open had helix pinning a core at 100% after ghostty exited.

Footnotes

1. Open URL, config, or scrollback relying on open.zig ↩ ↩²

2. libreoffice-writer is the only GUI app I have installed that advertises support for MIME text/plain, don't judge ↩

3. UNIX process lifecycle management language is as grim as ever ↩

[pluiedev]

This makes sense, as in we should at least not just fire-and-forget xdg-open invocations if they don't terminate themselves. Though I'm really having trouble understanding what the proposed solution is here

[jcollie]

#5988 should fix this once merged.

[AnthonyZhOon]

On a posix system, when a child-process exits it wants to notify its parent of a status change and stays around as a zombie until so. A wait() syscall or handling SIGCHILD in the parent allows the zombie to be cleaned up.
As we want to remain responsive and detach the xdg-open process, we can orphan and re-parent it to a subreaper which automatically waits on its children and cleans up.
A child-process becomes an orphan when it's parent process terminates, then its parent process id is updated to the init process or a nearest ancestor sub-reaper.
I think this is specific to the unix-model though, and a higher-level API specific to opening links does look good.

Orphan processes describes this.
An example in C is https://thinkiii.blogspot.com/2009/12/double-fork-to-avoid-zombie-process.html

[jcollie]

Yes, Zig's std.process.Child.spawn handles the fork/exec for us. #5988 changes things by running the spawn/wait in a separate thread from the other threads that Ghostty uses. That's why simply calling .wait() in the old open implementation caused Ghostty to become unresponsive.