Summary: | sys-apps/portage-2.2* with ipc USE-flag leave ebuild-ipc processes hanging around at "out of disk space" error | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Petr Polezhaev <NightNord> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 344555 | ||
Bug Blocks: |
Description
Petr Polezhaev
2010-11-14 21:22:07 UTC
The ebuild-ipc program has a 15 second timeout. If the processes are still hanging around after 15 seconds then it's not functioning correctly. Well, you're partially right. My testcase is somewhat not precise. If I'll run _single_ emerge process - all fine, ipc goes away after some timeout. But when I'm running few processes at once, for example emerge -1 openoffice and emerge -e -1 @world And after both process will fail (at same time), none of ebuild-ipc's will not perish anymore after any timeout. And once I've got message from failing emerge -1 openoffice * waiting for lock on fd 7 ... [ ok ] If you will run more emerge processes, especially with -j* option, you will get more "zombie" ipc's Also, this could happen with any other python-backtrace-error. For example, recently, I've encountered it, while running emerge openafs-kernel at one console and making ebuild openafs-kernel-1.4.12.1.ebuild clean at another, accidentally. It had lead to python-fail at first console, complaining about disappeared build.log and left one stale python-ipc process. Futhermore, merges after that found this python-ipc process as stale one, complaining about it at every merge phase. It seems like we just need to exert more control over nested subprocesses, as in bug 344555. AFAIK pid-sandbox handles this |