Bug 184405 - rhel4u3 ypserv seems broken (ypserv-2.13-9.x86_64)
Summary: rhel4u3 ypserv seems broken (ypserv-2.13-9.x86_64)
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: ypserv   
(Show other bugs)
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Chris Feist
QA Contact: Jay Turner
Depends On:
Blocks: 185334
TreeView+ depends on / blocked
Reported: 2006-03-08 16:21 UTC by Thomas J. Baker
Modified: 2015-01-08 00:11 UTC (History)
6 users (show)

Fixed In Version: 2.13-11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-20 18:23:56 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Updated dns-lookup patch (8.82 KB, patch)
2006-03-08 22:01 UTC, Chris Feist
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0263 normal SHIPPED_LIVE ypserv bug fix update 2006-03-13 05:00:00 UTC

Description Thomas J. Baker 2006-03-08 16:21:17 UTC
Description of problem:

I somewhat surprisedly received the RHEL4U3 update on my main ypserver this
morning (didn't receive an announcement on the enterprise watch mailing list)
and during the installation, the system started behaving badly, hanging, being
unresponsive, etc. I was forced to power cycle because the system wouldn't allow
login and didn't reboot after a c-a-delete. During boot, ypserv started up fine,
ypbind started up fine, autofs hung for several minutes, nfs quotas seemed to
completely hang and I went to the nahant mailing list only to find someone else
who had a problem with ypserv. So I booted single user, downgraded ypserv, and
everything was happy again. I expected to see logs of error messages but the
logs were empty.

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

How reproducible:

Couldn't take the time to reproduce since this is a production system.

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 daryl herzmann 2006-03-08 16:50:50 UTC
My situation was that I applied the ypserv update to the NIS server and the
clients soon started barking this:

do_ypcall: clnt_call: RPC: Timed out

And the NIS server started dumping these messsages

Mar  8 00:23:16 xxx ypserv[23967]: children is below 0 (-1)!
Mar  8 00:24:12 xxx ypserv[23967]: children is below 0 (-13)!
Mar  8 00:24:14 xxx ypserv[23967]: children is below 0 (-14)!

I restarted the ypserv a couple of times and some clients started to receive NIS
maps again, but the above error message kept coming with an increment of -1 for
each time a client did a lookup.  And some clients were still timing out.

I eventually gave up and downgraded to ypserv-2.13-5 to get things working again.

Comment 2 Chris Feist 2006-03-08 21:59:17 UTC
It appears the problem was caused by a call to a non-reentrant function (syslog)
within a signal handler.

This should be fixed in the rpms located here (2.13-11):

Can you please test these out to verify that they work with your system?

Comment 3 Chris Feist 2006-03-08 22:01:20 UTC
Created attachment 125837 [details]
Updated dns-lookup patch

This attachment contains the updated dns-lookup patch.

Comment 4 Bernd Bartmann 2006-03-08 22:01:59 UTC
I'm seeing the same problem here but on a 32 bit i686 hardware PIV CPU. I don't
see the "children is below 0" messages but whenever I try to restart ypserv I
get this in /var/log/messages:

Mar  8 22:49:19 picard ypserv: ypserv shutdown succeeded
Mar  8 22:49:24 picard ypserv: ypserv startup succeeded
Mar  8 22:49:24 picard ypserv[7956]: WARNING: no securenets file found!
Mar  8 22:49:24 picard ypserv[7956]: Support for SLP (line 20) is not compiled in.
Mar  8 22:49:24 picard ypserv[7956]: Support for SLP (line 22) is not compiled in.

Downgrading to ypserv-2.13-5 solves the problem for me too.

Comment 5 Bernd Bartmann 2006-03-08 22:04:51 UTC
ypserv-2.13-11 seems to fix the problem for me.

Comment 6 daryl herzmann 2006-03-08 22:06:42 UTC

Wow, thanks for the rapid response! :)  I installed i386 here and got these same

Mar  8 16:08:43 xxx ypserv: ypserv shutdown succeeded
Mar  8 16:08:43 xxx ypserv[23830]: Support for SLP (line 20) is not compiled in.
Mar  8 16:08:43 xxx ypserv[23830]: Support for SLP (line 22) is not compiled in.
Mar  8 16:08:43 xxx ypserv: ypserv startup succeeded

the NIS clients appear to be happy now tho.  So it appears to work, but I will
continue to monitor to any errors.

Comment 7 Boris 2006-03-08 23:26:39 UTC
The problme begins when i do a ypcat query to the server, after that rpc times
out. I have a full capture of tha transaction the fun part is that server gets
the requests and replies but client can't see it, but then there is that
DOMAIN_NONACK message. Also server dies to the point that ypinit -m update
function fails as well. 

up2date --get ypserv-2.13-5.i386.rpm
rpm -e ypserv-2.13-9
rpm -i ypserv-2.13-5.i386.rpm

untill they fix that.

Comment 8 Thomas J. Baker 2006-03-09 20:39:34 UTC
Seems to work for me too. I've installed it on two systems with no ill effects.

Comment 9 Northwestern Support 2006-03-09 21:15:32 UTC
We experienced the same as above. Works when first started, but fails sometime
later. Restarting makes it work for awhile again.  Doing /etc/init.d/ypserv
status shows that it is running, but doing a ps -ef |grep ypserv shows the
parent process and a child process which is labeled <defucnt>.  It appers it's
not able to clean up after itself.

I've downgraded to ypserv-2.13-5 like the others and that seems to work fine.

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