[🐛 BUG]: SIGSEGV in PHP worker causes full activity pool restart instead of single worker replacement

[koren88]

No duplicates 🥲.

• I have searched for a similar issue in our bug tracker and didn't find any solutions.

What happened?

When a PHP worker process receives SIGSEGV (e.g. via posix_kill(getmypid(), SIGSEGV) inside activity code), RoadRunner does not isolate the fault to that single worker. Instead, the entire activity pool is restarted — all 5 sibling workers are killed and replaced.
This is analogous to issue temporalio/roadrunner-temporal#699 which reported missing graceful handling for SIGQUIT/SIGUSR2. In that case the signal bypassed proper shutdown. Here the issue is that a fatal signal on one worker propagates to the whole pool, causing unnecessary disruption to in-flight activities on unaffected workers.

Version (rr --version)

Plugin / Component: roadrunner-temporal / activity pool
RoadRunner version: 2025.1.8 (buildtime: 2026-02-19)

How to reproduce the issue?

Add the following anywhere inside activity code:
phpposix_kill(getmypid(), SIGSEGV);

Relevant log output

[INFO] RoadRunner server started; version: 2025.1.8, buildtime: 2026-02-19T14:58:23+0000
WARN  RoadRunner can't communicate with the worker  {"reason": "worker hung or process was killed", "pid": 22, "internal_event_name": "EventWorkerError", "error": "sync_worker_receive_frame: Network: EOF"}
Activity error.  {"ActivityType": "AttributeTableIntegration.Process", "Attempt": 1, "Error": "activity_pool_execute_activity: Network:\n\tsync_worker_receive_frame: EOF"}
reset signal received, resetting activity pool
activity pool restarted

Worker table before (5 stable workers, PIDs 167–171):
┌─────┬────────┬───────┬────────┬───────┬───────────────┐
│ PID │ STATUS │ EXECS │ MEMORY │ CPU % │    CREATED    │
├─────┼────────┼───────┼────────┼───────┼───────────────┤
│ 115 │ ready  │ 9     │ 169 MB │ 0.92  │ 6 minutes ago │
│ 167 │ ready  │ 0     │ 162 MB │ 1.10  │ 5 minutes ago │
│ 168 │ ready  │ 0     │ 162 MB │ 1.11  │ 5 minutes ago │
│ 169 │ ready  │ 0     │ 162 MB │ 1.10  │ 5 minutes ago │
│ 170 │ ready  │ 0     │ 162 MB │ 1.10  │ 5 minutes ago │
│ 171 │ ready  │ 0     │ 162 MB │ 1.11  │ 5 minutes ago │
└─────┴────────┴───────┴────────┴───────┴───────────────┘
Worker table after (all 5 workers replaced, PIDs 350–354, high CPU spike during init):
┌─────┬────────┬───────┬────────┬───────┬───────────────┐
│ PID │ STATUS │ EXECS │ MEMORY │ CPU % │    CREATED    │
├─────┼────────┼───────┼────────┼───────┼───────────────┤
│ 115 │ ready  │ 14    │ 169 MB │ 0.85  │ 6 minutes ago │
│ 350 │ ready  │ 0     │ 160 MB │ 37.75 │ 7 seconds ago │
│ 351 │ ready  │ 0     │ 162 MB │ 37.52 │ 7 seconds ago │
│ 352 │ ready  │ 0     │ 162 MB │ 37.86 │ 7 seconds ago │
│ 353 │ ready  │ 0     │ 162 MB │ 37.86 │ 7 seconds ago │
│ 354 │ ready  │ 0     │ 162 MB │ 37.52 │ 7 seconds ago │
└─────┴────────┴───────┴────────┴───────┴───────────────┘

[rustatian]

Hey @koren88 👋🏻
The case is, that if the child process (worker) is stopped with a signal from itself, RR bridge to that worker would be broken. Thus you see in the logs, that RR can't communicate with that (already dead) process.
Thus, this is not about RR catching this signal (it should not, because that signal is for the child process). But the question is why the whole activity pool was restarted.
This mechanism works only in the temporal plugin, due to the nature of RR<->PHP communication internally in that plugin. Firstly, you should not stop workers by your own, like, firing signals to kill one of them. This will lead to the behavior you already observed (activity pool restart, except 1 workflow worker, at the top of the table). Second - that can happen due to some exception in PHP, definitely, but this is a rare case, and should not happen in production very commonly.

[koren88]

Hey @rustatian.
Thanks for the quick response and the detailed explanation! That really helps clarify where the responsibility lies.
Is the full activity pool restart on a single worker crash the intended behavior in roadrunner-temporal, or is this something that could/should be improved to only replace the affected worker?

[rustatian]

It is intended only for the roadrunner-temporal integration due to how that integration works. We use increasing ints to track requests and responses from the PHP workers (not a very intelligent mechanism). So if one process was killed, that mechanism breaks, and we would have to start from the beginning. I'm not sure if that is something that was already fixed on the PHP side; I've asked the PHP team that question, will return to you when I have the answer 😃

[rustatian]

Ok, so it looks like we can skip the restart of the whole activity pool if one of the workers dies. I'll reopen this issue to track the process of implementation.

[koren88]

Great news, thanks for checking with the PHP team! Looking forward to the fix. 🙏