| Summary: | Parallel startup hangs in busy wait (kernel dependent) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ed Catmur <ed> |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | 2004.3 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Hmm, the wait builtin is too sparse-featured to be useful here.
How about this hack:
sleep 60 &
trap "kill $!" SIGCHLD
fg
trap "" SIGCHLD
Sorry, that should be
sleep 60 &
trap "kill $!" SIGCHLD
fg
trap - SIGCHLD
|
Parallel startup hangs at various points. (At least, if it doesn't hang, it's stalling for over 10 minutes.) Investigation shows it is hanging in a busy wait at /lib/rcscripts/sh/rc-services.sh +622: # Wait until we have only one service running while [ "${count}" -gt 1 ] do count="$(jobs | tee /dev/stderr | grep -c "Running")" done This does happen only on certain kernels; in my case the nitro series 2.6.11 release candidates. I imagine this is preemption related, or other desktop performance features. I am using the CFQ scheduler, if that's relevant. Regardless, this busy wait is not good; even if it does not hang a system it is slowing down startup. Would a "sleep 0.1" be acceptable?