Bug 827267 - ypbind still fails
Summary: ypbind still fails
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: ypbind
Version: 17
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Honza Horak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 877789 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-01 00:46 UTC by Dave Close
Modified: 2012-11-19 13:39 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-07-09 10:55:00 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Dave Close 2012-06-01 00:46:03 UTC
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):
systemd-44-12.fc17.x86_64
ypbind-1.35-2.fc17.x86_64


How reproducible:
Every time.

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

Expected results:
ypbind succeeds

Additional info:

Comment 1 Honza Horak 2012-06-01 11:38:52 UTC
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 18:28:53 UTC
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 10:55:00 UTC
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 13:39:31 UTC
*** 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.