Bug 115725 - Binding to a NIS domain hangs startup
Binding to a NIS domain hangs startup
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: ypbind (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Steve Dickson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-15 08:25 EST by Martin Blom
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-12 10:28:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Martin Blom 2004-02-15 08:25:10 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.6) Gecko/20040206 Firefox/0.8

Description of problem:
Upgrading from FC1 to FC2 test 1 makes the startup hang (= wait for
several minutes, not lock up) at the NIS binding stage.

Booting interactivly, skipping this step and then doing to manually
using '/etc/init.d/ypbind restart' reproduces the problem.

Booting the original FC1 installation still works so nothing has
changed in our network.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Set up NISDOMAIN in /etc/sysconfig/network
2. Execute '/etc/init.d/ypbind restart'

    

Additional info:
Comment 1 Paul Black 2004-02-16 08:31:48 EST
I've seen the same on some of the machines I have with FC2 on. On the
machine that fails, it works if a server is specified (rather than
broadcastoing to find a server). Here's some info from tcpdump:

Working machine:
13:08:51.946389 IP vienna.oxsemi.com.32775 > 172.16.255.255.sunrpc:
UDP, length: 144
13:08:51.947446 IP mars.oxsemi.com.sunrpc > vienna.oxsemi.com.32775:
UDP, length: 36
13:08:51.957898 IP vienna.oxsemi.com.613 > mars.oxsemi.com.909: UDP,
length: 56
13:08:51.958062 IP mars.oxsemi.com.909 > vienna.oxsemi.com.613: UDP,
length: 28


Non-working machine:
13:05:47.323952 IP zurich.oxsemi.com.32773 > 172.16.255.255.sunrpc:
UDP, length: 112
13:05:53.324175 IP zurich.oxsemi.com.32773 > 172.16.255.255.sunrpc:
UDP, length: 112
13:06:01.324012 IP zurich.oxsemi.com.32773 > 172.16.255.255.sunrpc:
UDP, length: 112


The problem also seems to apply to rup and rusers.
Working:
13:21:11.952755 IP vienna.oxsemi.com.32976 > 172.16.255.255.sunrpc:
UDP, length: 112
13:21:11.953345 IP scallop.oxsemi.com.sunrpc >
vienna.oxsemi.com.32976: UDP, length: 136
13:21:11.953397 IP cockle.oxsemi.com.sunrpc > vienna.oxsemi.com.32976:
UDP, length: 136
13:21:11.953407 IP whelk.oxsemi.com.sunrpc > vienna.oxsemi.com.32976:
UDP, length: 136
13:21:11.953520 IP winkle.oxsemi.com.sunrpc > vienna.oxsemi.com.32976:
UDP, length: 136

Non-working:
13:22:46.947609 IP zurich.oxsemi.com.32775 > 172.16.255.255.sunrpc:
UDP, length: 108
13:22:50.948020 IP zurich.oxsemi.com.32775 > 172.16.255.255.sunrpc:
UDP, length: 108
13:22:56.948054 IP zurich.oxsemi.com.32775 > 172.16.255.255.sunrpc:
UDP, length: 108
Comment 2 Martin Blom 2004-02-16 09:30:33 EST
Indeed. Changing "broadcast" to "server <server>" in /etc/yp.conf
makes the problem disappear.
Comment 3 Paul Black 2004-02-17 11:59:39 EST
I think it's a kernel problem, etherreal reckons the UDP checksum is
wrong for broadcast packets.
Comment 4 John Thacker 2006-10-29 17:47:01 EST
[This is a mass update sent to many bugs that missed earlier such messages due
to having their version set to a test version.]

This bug was originally filed against a version of Fedora Core which is no
longer supported, even for security updates.  Many changes have occured since
then.  Please retest this bug against a still supported version.  Note that FC3
and FC4 are supported by Fedora Legacy for security fixes only.  If
it still occurs on FC5 or FC6, please assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.

This bug will be closed after a few weeks if no information is given indicating
that the bug is still present in a supported release.
Comment 5 John Thacker 2007-01-12 10:28:13 EST
Closing per lack of response to previous request for information.
This bug was originally filed against a much earlier version of Fedora
Core, and significant changes have taken place since the last version
for which this bug is confirmed.

Note that FC3 and FC4 are supported by Fedora Legacy for security
fixes only.  Please install a still supported version and retest.  If
it still occurs on FC5 or FC6, please reopen and assign to the correct
version.  Otherwise, if this a security issue, please change the
product to Fedora Legacy.  Thanks, and we are sorry that we did not
get to this bug earlier.

Note You need to log in before you can comment on or make changes to this bug.