[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::digital_unix

Title:	DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:	Welcome to the Digital UNIX Conference
Moderator:	SMURF::DENHAM

Created:	Thu Mar 16 1995
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	10068
Total number of notes:	35879

8804.0. "ypxfr could not send clear map" by KERNEL::NICHOLSONA (one suite too many can cause truth decay) Wed Feb 12 1997 09:23

    
    
    Hi,
    
    A customer of mine upgraded from 3.2c to 3.2g. He found that wne
    trying to make a hosts database (because he had change a host
    address) that during the make of the host database he got the following
    error
    
    status received ypxfr on congo (slave) map successfully transferred
    ypxfr could not send clear map.
    
    This was trying to ypxfr the map from the MASTER to a SLAVE server both
    running 3.2g. 
    
    ypcat on the SLAVE seemed to indicate it did indeed have an updated
    host database, however when the slave tried to ping the host with the
    new address it was still trying the old address.
    
    The customer rebooted and now everything appears to be ok.
    
    Could someone tell me what 
    
    "ypxfr could not send clear map"
    
    means and what is the cause.
    
    Thanks
    Avril

T.R Title User Personal
Name Date Lines

8804.1 what ypclear does NETRIX::"[email protected]" Farrell Woods Wed Feb 12 1997 15:26 24

T.R	Title	User	Personal Name	Date	Lines
8804.1	what ypclear does	NETRIX::"[email protected]"	Farrell Woods	`Wed Feb 12 1997 15:26`	24
	As you may know, ypxfer is responsible for copying a new map from a master server to a slave server. It creates the new map off to one side, then does a "rename" to move the new map over the old map in one fell swoop. But the ypserv process may still be holding the old map open, which could cause it to respond to requests with stale data. It sounds like that's what you're seeing. The very last thing that ypxfer does is it sends a message to ypserv to tell it to close any maps that it currently has open. The next request to come along will cause ypserv to open the "new" map that ypxfer just slid into place. For some reason ypxfer could not send this clear message to ypserv. Did ypserv happen to log any suspicious messages? I can't think of any good reasons off the top of my head for such a failure. Looking at the code in ypxfr I see: ypxfr can't get the host name of the machine it's running on, it can't bind to the ypserv process on that host, or the RPC call itself failed. -- Farrell [Posted by WWW Notes gateway]

As you may know, ypxfer is responsible for copying a new map from a master
server to a slave server.  It creates the new map off to one side, then
does a "rename" to move the new map over the old map in one fell swoop.

But the ypserv process may still be holding the old map open, which could
cause it to respond to requests with stale data.  It sounds like that's
what you're seeing.

The very last thing that ypxfer does is it sends a message to ypserv
to tell it to close any maps that it currently has open.  The next request
to come along will cause ypserv to open the "new" map that ypxfer just
slid into place.

For some reason ypxfer could not send this clear message to ypserv.  Did
ypserv happen to log any suspicious messages?  I can't think of any good
reasons off the top of my head for such a failure.  Looking at the code
in ypxfr I see: ypxfr can't get the host name of the machine it's
running on, it can't bind to the ypserv process on that host, or the RPC
call itself failed.


	-- Farrell

[Posted by WWW Notes gateway]