Summary: | sys-apps/portage: kill background subprocess of ebuilds, such as dbus-launch | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Jimmy.Jazz |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | esigra, kensington, pacho |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=503532 https://bugs.gentoo.org/show_bug.cgi?id=659582 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 184128, 345455 |
Description
Jimmy.Jazz
2010-11-07 17:29:33 UTC
We should be able to use setsid to create a new login session, and then kill everything in that session when the ebuild exits. However, such a session does not receive signals from the user's controlling terminal, so we'll have to use ipc to pass kill signals from the main portage process to the new login session. Similarly to bug #278895, the fix will be conditional on USE=ipc. (In reply to comment #2) > Similarly to bug #278895, the fix will be conditional on USE=ipc. Actually, the session daemon ipc will likely be much less error-prone than the fifo ipc that USE=ipc currently controls, so the session daemon ipc will either be unconditional or else be controlled by a separate USE flag. What is the best practice regarding this issue? Should ebuilds be trying to clean up their stray processes themselves, or is it reasonable to expect the package manager to do this? (In reply to Michael Palimaka (kensington) from comment #4) > What is the best practice regarding this issue? Should ebuilds be trying to > clean up their stray processes themselves, or is it reasonable to expect the > package manager to do this? Portage currently does not try to kill any child processes that the ebuild has spawned, so for now it's nice if the ebuild makes some kind of effort to kill them itself. Eventually though, ebuilds should able to rely on the package manager to handle it. See bug #465008, comment #7 for related discussion involving PMS. Is there anything to do here now we have FEATURES="ipc" ? (In reply to Michael Palimaka (kensington) from comment #7) > Is there anything to do here now we have FEATURES="ipc" ? If you have FEATURES="cgroup ipc" enabled, then that may do the trick. We could also implement a portable alternative to cgroup that uses a new terminal session to encapsulate the ebuild process and its children, as mentioned in bug 465008, comment #7. (In reply to Zac Medico from comment #8) > If you have FEATURES="cgroup ipc" enabled, then that may do the trick. Actually, ipc is a USE flag that's enabled by default via use.force, not a FEATURES setting. Anyway, FEATURES="cgroup" may do the trick as long as you haven't forcibly disabled ipc. Why FEATURES "cgroup" is not enabled by default? (In reply to Pacho Ramos from comment #10) > Why FEATURES "cgroup" is not enabled by default? It's a relatively new feature. It's probably had enough testing that we could enable it by default now. We've actually since removed FEATURES="cgroup" but FEATURES="pid-sandbox" is default-on. |