Bug 236865 - service ypbind start fails to start ypbind
service ypbind start fails to start ypbind
Product: Fedora
Classification: Fedora
Component: ypbind (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Steve Dickson
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2007-04-17 22:24 EDT by david.hagood
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-20 10:34:32 EDT
Type: ---
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 david.hagood 2007-04-17 22:24:37 EDT
Description of problem:
running the ypbind init script fails to start ypbind - or rather, it starts it,
then kills it.

Starting the ypbind daemon by hand works - the domain is bound, and users are
properly authenticated against the NIS directory.

However, launching the script causes the server to start, but then when the
script tries to verify that ypbind is running (by using rpcinfo) it fails to see
what it wants, decides that ypbind is not running, and shuts it down.

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

rpm -qf /usr/sbin/rpcinfo /sbin/ypbind 

How reproducible:
every time

Steps to Reproduce:
1. service ypbind restart
Actual results:
 service ypbind restart
Shutting down NIS services:                                [  OK  ]
Turning off allow_ypbind SELinux boolean
Turning on allow_ypbind SELinux boolean
Binding to the NIS domain:
Listening for an NIS domain server...............                                
Turning off allow_ypbind SELinux boolean..............     [FAILED]

During this the time the "Listening for an NIS domain server" message is
showing, running a "ps ax | grep ypbind" on another session shows the ypbind
daemon is running.

Running /usr/sbin/rpcinfo during that time yields:

   program version netid     address                service    owner
    100000    4    tcp6      ::.0.111               portmapper superuser
    100000    3    tcp6      ::.0.111               portmapper superuser
    100000    2    tcp6      ::.0.111               portmapper superuser
    100000    4    udp6      ::.0.111               portmapper superuser
    100000    3    udp6      ::.0.111               portmapper superuser
    100000    2    udp6      ::.0.111               portmapper superuser
    100000    4    local     /v                     portmapper superuser
    100000    3    local     /v                     portmapper superuser
    100000    2    local     /v                     portmapper superuser
    100024    1    udp6      ::.2.156               status     unknown
    100024    1    tcp6      ::.2.159               status     unknown
    100021    1    tcp6      ::.189.252             nlockmgr   unknown
    100021    3    tcp6      ::.189.252             nlockmgr   unknown
    100021    4    tcp6      ::.189.252             nlockmgr   unknown
    100007    2    udp6      ::.3.169               ypbind     unknown
    100007    1    udp6      ::.3.169               ypbind     unknown
    100007    2    tcp6      ::.3.172               ypbind     unknown
    100007    1    tcp6      ::.3.172               ypbind     unknown

Also, during that time, normal user logins (authenticated via NIS) work.

After that time, ypbind is shut down.

Expected results:
ypbind should start, run, and CONTINUE to run.

Additional info:
Comment 1 Steve Dickson 2007-04-18 09:39:05 EDT
yes this is a bit bizarre... is there anything 
logged in /var/log/messages gives a clue to
what is failing?

Just yesterday I fixed a couple of bugs in
ypbind's init script that may or may not 
help with the problem. One thing that the
new init script will do is log any and all
errors in /var/log/messages. So could you 
please try the new ypbind rpm either by doing
an yum update ypbind or by graping it from
Comment 2 david.hagood 2007-04-18 21:19:44 EDT
First weird thing: when I tried to install your packages, I was unable to do so
because yp-tools was not installed - so either
a) you just added that dependency to the RPM
b) yum is installing things without all the prerequisites.

Having installed yp-tools I was able to install your packages, and now ypbind
starts normally.

So either
a) the problem was the missing yp-tools package
b) your fixes corrected the problem.

(don't you just hate it when you cannot nail down what really solved the problem?)

It might be interesting to check the requires on the current ypbind package to
see if it lists yp-tools as a dependency or not.

Comment 3 Steve Dickson 2007-04-20 10:34:32 EDT
Yeah that is a bit strange that you had ypbind installed without
yp-tools being that dependency has been around a long time...

But I'm glad to hear the latest ypbind patckages is working
for you...  

This version of ypbind has been taged for the final release
of FC7 but you can also find it in the rawhide tree.

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