In my Vala app, I’m starting a child program (wget command) asynchronously with GLib.Process.spawn_async(…) function. It works fine and it sends back the process id (thanks to “out child_pid” parameter in the function call). Later in my app (at user request), I want to be able to kill that process with Process.close_pid (child_pid);
Important : I build and run my app within Flatpak environment (this is the origine of my current issue)
What happens :
- the child program is launched and it runs fine (I can see its process with ps command on the host and I can see that process with a host PID (like 28042 for example). I don’t see any process with “flatpak ps” command => it’s running at host level, not at flatpak level
- but the child_pid that is returned by spawn_async function is a pid inside the flatpak environment (like 13 for example), not the pid at host level. And by consequence, when I do a Process.close_pid(child_pid) it doesn’t close the child program process.
Do you know a way to get the pid inside the host environment instead of inside the flatpak environment ? Or is there a way for spawn_async() function to start the program inside the flatpak environment ?
Thanks in advance
It should be impossible for spawn_async() to escape the Flatpak sandbox. If this were truly happening as you describe, then you’d have found a major security bug and it would be big news. I think you’re misunderstanding what
flatpak-ps does. That just lists processes started by flatpak itself, including processes started via
flatpak-spawn. Processes that are started by your application won’t be listed there unless you go via
flatpak-spawn. Your process is still running inside the sandbox.
flatpak processes are confined in a pid namespace. There is no way for them to see host pids unless the flatpak app has a static permission that allows it to disable that protection (not recommended). Accordingly, you’ll not be able to use or interact with host pids, but that’s fine: you should be able to use the pids you see inside the pid namespace like normal.
So this is expected.
Check the documentation of this function. It doesn’t do anything except on Windows. You’re going to want to find some other way to stop your subprocess, e.g.
You may just want to use libsoup for better control over HTTP transfers, instead of shelling out to wget.
Thanks for your answer. I’m busy right now but I will take time to read again your points, think and check the documentation and do more testing.
You’re right but i don’t want to redo what wget already does very nicely (in my opinion). And my interest in that app development was first mainly aimed at learning development in Gnome/GTK environment.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.