If you are rebuilding the server, you should at least do a vos remsite for
each of the volumes on the server. You could get this information from
vos listvldb. (You might want to write a script to process its output.)
The vos remsite command doesn't actually remove the volumes from the server,
it just removes the server from the volume's vldb entry.
By doing this, you are preventing clients from attempting to bind to that
fileserver and avoiding failures during releases of those volumes.
Other than that (as long as it is not a database server), removing it should
be no big deal. Given your list of errors, it seems a rebuild of the
server from scratch might be the best policy.
-- Garrett.
On Mon, 29 Jul 1996 18:46:14 -0500 Andrew Mickish wrote:
> What is the procedure for removing a file server from the cell?
> Can you turn it off, then later tell the cell to forget about it,
> or do you have to interact with the machine to get it out of the cell?
>
> We have a Solaris 5.3 machine that was intended as a test platform when we
> first set up the cell, but it has developed problems (independent of AFS)
> that require rebuilding. It has AFS volumes, but refuses to serve them.
> Before wiping its disk, I thought it would be nice to officially say goodbye.
>
> Here is some of its nasty behavior (it is named pvtserver):
>
> # fs checkservers
> These servers unavailable due to network or server problems: pvtserver.
>
> # vos examine sun4m_53
> Could not fetch the information about volume 536870957 from the server
> Possible communication failure
> Error in vos examine command. Possible communication failure
> Dump only information from VLDB
> sun4m_53
> RWrite: 536870957
> number of sites -> 1
> server pvtserver partition /vicepa RW Site
>
> # vos listvol pvtserver
> Could not fetch the list of partitions from the server
> Possible communication failure
> Error in vos listvol command. Possible communication failure
>
> # bos status pvtserver
> Instance upserver, currently running normally.
> Instance upclientetc, temporarily disabled, stopped for too many errors,
> currently shutdown.
> Instance runntp, currently running normally.
> Instance fs, has core file, currently running normally.
> Auxiliary status is: salvaging file system.
>
>
> Any insights about what condition this machine appears to be in would be
> appreciated.
>
> --Andrew Mickish
> http://www.mc.vanderbilt.edu/~mickish
>
