From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031023
Description of problem:
If a cipe interface is configured to come up at boot time, but the network
interface that provides the default route fails to be brought up on boot (e.g.,
unplugged laptop or failed ppp0 authentication with ISP), the boot will fail, in
that bringing up the cipe interface will never complete, and the only way out of
this is a reboot, either after connecting the computer to a network, or in
single-user mode, disabling the ONBOOT configuration of the cipe channels, then
letting it complete the boot.
Ideally, bringing up the cipe channel should time out just like other network
It seems to be a race condition in ciped. It clone()s, changes some signal
masks, then pause()s. Within strace, the cloned process gets control only after
pause(), but I guess without strace, it gets control first, and exit()s before
the parent blocks SIG_CHLD to pause(), so it handles the signal, then blocks it
and pause()s forever. More details in bug 103516, the original, FC version of
this bug report.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Set up a cipe channel configured to come up at boot time
2.Unplug the host from the network
Actual Results: It will fail to bring eth0 up, and then bringing up of the cipe
channel will never complete
Expected Results: It should time out in a few seconds
*** Bug 103516 has been marked as a duplicate of this bug. ***
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.