Red Hat Bugzilla – Bug 815978
ypbind fails upon boot
Last modified: 2012-08-08 11:52:24 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 2. 3. 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.
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: https://admin.fedoraproject.org/updates/FEDORA-2012-6135/ypbind-1.35-2.fc17 then log in and leave karma (feedback).
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.
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 ypbind-1.35-5.fc16.x86_64
Okay, I'm going to open a new bug on this. Although your note says "re-open" I apparently can't do that....