Repository navigation
[shell] Add option to spawn command in process group #1332
Description
this is basically the fix to issues like pyinstaller apps not being killed because pyinstaller wraps the actual app in a thin parent process that doesn't clean up after itself.
v1's command code was a bit too much for me to find motivation tbh but in this plugin it should be fairly straight forward.
Since may be use cases where this is not desirable, it will be a simple boolean option.
The implementation should use https://github.com/watchexec/process-wrap, the successor of command-group.
p.s. just opening this issue so i don't forget about it until next week, not asking the team to work on this (however, if a community member wants to work on this then i'd be quite happy about it)
Activity
mitulagr2 commentedon Jul 13, 2025
Hi, is this in progress?
FabianLars commentedon Jul 13, 2025
No. I started it a few weeks/months ago but it was more annoying to implement than expected. Not even sure if I still have the local branch, gonna check on Monday.
If you're asking cause you want to pick it up then go for it :)
elibroftw commentedon Oct 26, 2025
Is there any API stub? I don't need this feature anymore since I came up with my own solution to the problem but if I ever get the time I'd be happy to help since it makes my code redundant.
Like just add an option to spawn in a group basically?
FabianLars commentedon Oct 26, 2025
That was the idea, yeah. Perhaps not realistic though. I think I lost the very-wip branch I worked on a few months ago though, will check later.
Noremac11800 commentedon Jan 21, 2026
@FabianLars any news on this? This is issue is the last piece of the puzzle I need to get my app up and running. I have an idea of how I'm going to get around it, but it requires significantly more Rust code than I was hoping I would need to write. Ideally, child processes would have a
kill_all()option instead of justkill()which would recursively terminate child processes produced by my original parent.I don't have the ability to make the parent process cleanup its children and their children because the grandchild processes are 3rd party. My best attempt so far, without writing a more robust solution, is to target killing PIDs by process name, but that approach is fragile and hacky.
feat(shell): add process group spawn option (fix tauri-apps#1332)
test(shell): add PyInstaller simulation tests for process group kill
feat(shell): add process group spawn option (fix tauri-apps#1332)
test(shell): add PyInstaller simulation tests for process group kill
aka-danielZhang commentedon Aug 18, 2026
Field report from a Tauri 2 app that currently rolls its own sidecar supervision: our Rust shell spawns a long-lived Node sidecar directly (not via the shell plugin), and we just moved it to
process_group(0)+kill(-pgid, SIGTERM)with a grace-then-SIGKILLladder on macOS. That plus a pid registry eliminated the orphan accumulation we were seeing (9 orphaned sidecars after a singletauri devsession before; 0 after) — about 30 lines of std + libc, no tree walking, no TOCTOU races between "enumerate children" and "kill them".A process-group option in the shell plugin via
process-wrapwould let apps like ours drop the hand-rolled ladder entirely. Happy to test a draft on macOS against a real long-lived sidecar workload (our sidecar routinely has live child processes of its own).One design note from our experience: process groups cover every descendant that doesn't call
setsiditself; sandbox executors that do will still escape, so we keep a small pid +ps lstartregistry swept on next boot as the last-resort net. Aprocess-wrap-based option gets Job Objects on Windows, which covers that hole natively there.feat(shell): add process group spawn option (fix tauri-apps#1332) (ta…