I see this in a particularly annoying way. apt-get when run from another tool (like puppet) will have /dev/null for stdin. apt-get foolishly select(2)s on stdin which results in 100% cpu usage (stdin is always ready when it is /dev/null). This 100% cpu qualifies for the fork-blocking, and since apt-get forks dpkg (which again forks dpkg) during installation, dpkg never actually forks, so apt-get stalls the entire system for hours if it ever even comes back.
I found a work around for *only* the apt-get or similar situations in that running the process through nice(8) seems to allow fork to unwedge. This is obviously impractical for low-latency services like databases, etc, but can help for others. -- You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. https://bugs.launchpad.net/bugs/708920 Title: Strange 'fork/clone' blocking behavior under high cpu usage on EC2 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
