Bug 815978 - ypbind fails upon boot
ypbind fails upon boot
Product: Fedora
Classification: Fedora
Component: ypbind (Show other bugs)
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Honza Horak
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-04-24 18:45 EDT by Ray Mikkelson
Modified: 2012-08-08 11:52 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-05-03 03:18:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ray Mikkelson 2012-04-24 18:45:32 EDT
Description of problem:
Just did an yum update today, and immediately after rebooting, noticed that ypbind is not starting correctly immediately after a boot.

(I had done a yum update on 4/16/12 and didn't notice any problems until today, 4/24/12, when I first noticed this problem.)

I'm not sure if the problem started on 4/16 with the ypbind update and I didn't notice it, or if it started today.  Note that today's update did not update ypbind.  (So, it might be some interaction with another process.)

This problem occurs on 2 different servers in my network, both of which were updated recently.  This probelm does not seem to occur on the previous version of ypbind (3:1.33-11.fc16).

Version-Release number of selected component (if applicable):
ypbind.x86_64                           3:1.35-1.fc16                @updates   

How reproducible:
Fails every time

Steps to Reproduce:
1. Just boot your box
Actual results:
ypbind fails to "attach" to the ypserver.  The ypbind process is still running, however.

Expected results:
ypbind succeeds

Additional info:

From my /var/log/messages file:
(mybox is the hostname)

From section during the boot:

Apr 24 10:51:18 security ypbind-pre-setdomain[943]: Setting NIS domain: 'hs.domain' (environment variable)
Apr 24 10:51:18 mybox ypbind: Binding NIS service
Apr 24 10:52:04 mybox ypbind: Binding took 46 seconds
Apr 24 10:52:04 mybox ypbind: NIS domain: hs.domain, ypbind not registered with rpcbind.

(Note that during the boot, the time is off by 6 hours until chronyd starts)

After doing a systemctl restart ypbind.service:

Apr 24 16:54:50 mybox ypbind: Binding NIS service
Apr 24 16:54:50 mybox ypbind: Binding took 0 seconds
Apr 24 16:54:50 mybox ypbind: NIS domain: hs.domain, NIS server: myypserver

The hardware is a Dell Optiplex 390.
Comment 1 Honza Horak 2012-04-25 01:27:26 EDT
Thanks for the report. I believe, this is the same issue as bug #812501. A
fixed build is already in updates-testing and will be pushed to stable soon. Until then, feel free to try the build in updates-testing:

Package ypbind-1.35-2.fc17:
* should fix your issue,
* was pushed to the Fedora 17 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing ypbind-1.35-2.fc17'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
Comment 2 Honza Horak 2012-05-03 03:18:59 EDT
The new build above is already available in fedora-updates. In case you're hitting this issue, please, try to update ypbind.

In case the issue remains even with ypbind-1.35-2 or later, feel free to re-open this bug.
Comment 3 Roland Roberts 2012-08-08 11:50:43 EDT
This appears to have resurfaced, at least I'm having the same problem with 1.35-5 also on x86_64 hardware.

I'm not clear on what's happening under the hood, but NetworkManager appears to have not fully started when ypbind kicks off. I'm attaching an extract from my syslog. ypbind starts just fine once I can log into the console. I also have to restart autofs to get my automounts to work since ypbind wasn't running when that kicked off.

[root@airy ~]# uname -isrvmpio
Linux 3.4.7-1.fc16.x86_64 #1 SMP Mon Jul 30 16:37:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[root@airy ~]# rpm -q ypbind
Comment 4 Roland Roberts 2012-08-08 11:52:24 EDT
Okay, I'm going to open a new bug on this. Although your note says "re-open" I apparently can't do that....

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