fix: PR_SET_PDEATHSIG kills Chrome in tokio multi-threaded runtime (v0.24.1 regression)

[shtefcs]

Bug Description

v0.24.1 introduced prctl(PR_SET_PDEATHSIG, SIGKILL) in Chrome's pre_exec hook (PR #1137) to prevent orphaned Chrome processes when the daemon is SIGKILL'd. However, this causes Chrome to be killed after ~7 seconds of idle time on every page, every site.

Root Cause

PR_SET_PDEATHSIG tracks the thread that called fork(), not the process. This is documented in the prctl(2) man page:

"the 'parent' in this case is considered to be the thread that created this process"

The agent-browser daemon uses tokio's multi-threaded runtime. The worker thread that spawns Chrome via Command::spawn() (which calls fork()) gets recycled by tokio after a few seconds of idle time. When the thread exits, the kernel sends SIGKILL to Chrome — even though the daemon process is still alive.

Reproduction

# v0.24.0 — works fine
agent-browser open https://example.com
sleep 15
agent-browser get url  # → https://example.com/ ✅

# v0.24.1 — Chrome dies
agent-browser open https://example.com
sleep 10
agent-browser get url  # → about:blank ❌ (Chrome was killed and auto-relaunched)

Tested with:

• Zero env vars, zero custom args, pure v0.24.1 binary
• Happens on every site (example.com, wikipedia.org, etc.)
• Happens in both headless and headed mode
• Does NOT happen on v0.24.0 or v0.23.0

Impact

• All pages navigate to about:blank after ~7-9 seconds
• Download workflows are completely broken (first download works, second fails because Chrome died between actions)
• Live preview streaming shows resolution changes (Chrome auto-relaunches with default viewport)
• Any automation that takes >7 seconds between commands fails

Proposed Fix

Replace PR_SET_PDEATHSIG with a sentinel process + keepalive pipe:

1. Before spawning Chrome, create a pipe
2. After Chrome starts, fork a tiny sentinel process that:
   • Joins Chrome's process group (setpgid)
   • Blocks on reading the pipe's read end
3. Daemon keeps the pipe's write end open (process-scoped fd, shared by all threads)
4. When daemon dies (ANY reason including SIGKILL):
   • Kernel closes all daemon fds → pipe breaks
   • Sentinel reads EOF → kills Chrome process group via kill(-pgid, SIGKILL)

This correctly handles:

• ✅ Tokio worker thread recycling (pipe fd is process-scoped, not thread-scoped)
• ✅ Daemon SIGKILL'd (kernel closes pipe → sentinel kills Chrome)
• ✅ Daemon graceful exit (process group kill in Drop + pipe close)
• ✅ Works on Linux (no macOS equivalent needed — process group kill handles macOS)

Validation

Built v0.24.1 with the sentinel fix:

• Page stays for 15+ seconds idle ✅
• 5 downloads with 10s delays work ✅
• SIGKILL daemon → Chrome + all helpers + sentinel = DEAD, zero orphans ✅

Alternative Approaches Considered

Approach	Why not
pidfd_open (Linux 5.3+)	Not available on older kernels
Dedicated std::thread for spawn	Workaround, doesn't fix the fundamental issue
PID polling (getppid() == 1)	Polling delay, not instant
Remove PR_SET_PDEATHSIG entirely	Loses SIGKILL orphan prevention

Related

• PR fix: prevent orphaned Chrome processes on daemon exit #1137 introduced PR_SET_PDEATHSIG
• Issue Orphaned headless Chrome processes block normal Chrome from launching #1113 (orphaned Chrome processes) was the original motivation
• PR fix: idle timeout not respected due to sleep future reset in select loop #1110 (idle timeout fix) was initially suspected but is unrelated

[ctate]

This was fixed in v0.25.2 (#1157, #1173). PR_SET_PDEATHSIG was removed and orphan cleanup now relies on the process-group kill in ChromeProcess::kill() via setpgid(0, 0) + kill(-pgid, SIGKILL). Closing as resolved.

[ctate]

This was fixed in v0.25.2 (#1157, #1173) by removing PR_SET_PDEATHSIG and relying on process-group kill instead. Thanks for the thorough root cause analysis. Please reopen if you're still seeing this on the latest version.

[IamMrandrew]

Coming from issue #1177, despite this PR shows the fix is completed, the about:blank navigation issue still persists when running commands sequentially in separate shell invocations.

Environment

• OS: Linux (Docker container)
• Browser: Headless Chromium (@sparticuz/chromium)
• Working version: 0.24.0
• Broken version: 0.26.0

Steps to Reproduce

1. Start the browser and navigate in a standalone command:

AGENT_BROWSER_EXECUTABLE_PATH=/tmp/chromium agent-browser --args "--no-sandbox,--disable-gpu" open https://news.ycombinator.com

2. Wait a brief moment (e.g., sleep 2).
3. Check the URL or take a snapshot in a new command:

agent-browser get url

Expected Behavior

The second command should return the current page URL (https://news.ycombinator.com/) and the DOM state should be preserved.

Actual Behavior

The browser reverts to about:blank and the DOM snapshot is completely empty.

Diagnostic Evidence

In 0.26.0, if the commands are chained together (e.g., open ... && get url) or executed using the batch command (agent-browser batch "open ..." "get url"), it works perfectly. The page only resets to about:blank when the commands are executed as separate CLI invocations. In 0.24.0, separate invocations work flawlessly.

Workaround

1. Downgrade to 0.24.0.
2. Alternatively, in 0.26.0, strictly use the batch command or shell chaining (&&) to group all actions into a single CLI execution.