Bug 827267 - ypbind still fails
ypbind still fails
Product: Fedora
Classification: Fedora
Component: ypbind (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Honza Horak
Fedora Extras Quality Assurance
: 877789 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2012-05-31 20:46 EDT by Dave Close
Modified: 2012-11-19 08:39 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-07-09 06:55:00 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 Dave Close 2012-05-31 20:46:03 EDT
Description of problem:
May 31 17:16:32 pses04top setsebool[8968]: setsebool:  SELinux is disabled.
May 31 17:16:32 pses04top ypbind: Binding NIS service
May 31 17:17:18 pses04top ypbind: Binding took 46 seconds
May 31 17:17:18 pses04top ypbind: NIS domain: dom1, ypbind not registered with rpcbind.

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

How reproducible:
Every time.

Steps to Reproduce:
1. systemctl start (or restart) ypbind.service
Actual results:
ypbind fails

Expected results:
ypbind succeeds

Additional info:
Comment 1 Honza Horak 2012-06-01 07:38:52 EDT
It works for me with the same builds. From what I see in your syslog output, I'd guess there's some communication problem with ypserv. I have some questions to make a better picture about your environment:

Do you run ypbind/ypserv on the same machine or on two different machines?
Do domain name correspond on client/server?
What is the output of "ypbind -d" and does ypbind work when running this way?
What is the output of "rpcinfo -p" during systemctl start ypbind.service is running (which should take some time according your log)?
Are you using Network Manager or network service?
Comment 2 Dave Close 2012-06-01 14:28:53 EDT
The machine in question has two interfaces, one wired and the other wireless. The wired interface was marked NM_CONTROLLED=no and the wireless one was NM_CONTROLLED=yes and ONBOOT=no. So both NetworkManager and the network service were active. The wired interface was active and was the route to NIS.

Your comments provided the clue that resolved the issue. Running ypbind -d showed that ypbind was not trying to use the wired interface because it detected NetworkManager active and NetworkManager was not controlling the wired interface. Changing that interface to NM_CONTROLLED=yes and restarting NetworkManager allowed ypbind to start and bind properly.

So, while my problem is solved, this seems to indicate to me that merely detecting NetworkManager active should not be sufficient to presume that it is controlling the interface ypbind needs to use.
Comment 3 Honza Horak 2012-07-09 06:55:00 EDT
I've consulted this use-case with Thorsten from upstream. We agreed, that your solution is right (either use -no-dbus or let all interfaces be controlled by NM) and there is probably no way how to make ypbind more clever in this case.
Comment 4 Honza Horak 2012-11-19 08:39:31 EST
*** Bug 877789 has been marked as a duplicate of this bug. ***

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