My original problem about ypxfr being slooooow in 3.0
> What's this "hi-speed daemon" and how can I start it? Or alternatively
> how do I tell the slaves not to try to use it so that it wouldn't wait
> any rpc timeouts when transfering the maps?
ypxfrd seems to be buggy in 3.0, and replacing it with a fixed
one seems to help.
Answers:
I think you will find that requesting the following patch will solve the
problem:
/usr/sbin/ypxfrd (HPXQ74e02)
CHECKSUM: 43643 47
---------------------
Patch ID: OSFV30-006-1
The NIS transfer daemon ypxfrd may dump core when transferring an NIS map.
This does not cause the transfer to fail, the transfer is completed using
another method. It does cause a core file to appear in the / directory
and it slows down the completion of the transfer considerably.
ypxfrd dumps core roughly half of the time.
I check for patches at
http://www.service.digital.com:8031/
Hi,
yp has got two methods for transfering NIS maps. The faster method is using
the ypxfrd. If this fails, yp takes a slower mechanism for the transfer.
There are some fixes in the yp area. Pls. contact your local support
center, if they can provide you the patches.
Thanks to:
luchini_at_siberia.ups-tlse.fr (Marco Luchini)
<linnartz_at_col01.enet.dec.com>
Received on Wed Jan 18 1995 - 10:39:18 NZDT