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):
Couldn't take the time to reproduce since this is a production system.
Steps to Reproduce:
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: children is below 0 (-1)!
Mar 8 00:24:12 xxx ypserv: children is below 0 (-13)!
Mar 8 00:24:14 xxx ypserv: 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.
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?
Created attachment 125837 [details]
Updated dns-lookup patch
This attachment contains the updated dns-lookup patch.
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: WARNING: no securenets file found!
Mar 8 22:49:24 picard ypserv: Support for SLP (line 20) is not compiled in.
Mar 8 22:49:24 picard ypserv: Support for SLP (line 22) is not compiled in.
Downgrading to ypserv-2.13-5 solves the problem for me too.
ypserv-2.13-11 seems to fix the problem for me.
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: Support for SLP (line 20) is not compiled in.
Mar 8 16:08:43 xxx ypserv: 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.
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.
Seems to work for me too. I've installed it on two systems with no ill effects.
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.