On Tue, Apr 10, 2001 at 11:47:13AM -0400, Jan Harkes wrote:
> On Tue, Apr 10, 2001 at 04:00:43PM +0100, Dermot Cassidy wrote:
> > ilo102-/coda $ cfs mkmount /coda/users rs.users
> > ilo102-/coda $ echo $?
> > 0
> > ilo102-/coda $ ls -l
> > total 0
> > lrw-r--r--  1 1002  nobody  10 Apr 10 14:58 users -> #rs.users
> 
> Ok, the updateclnt/updatesrv daemon didn't propagate the new VLDB and
> VRDB files to all servers. The volume is not mounted.
> 
> > ilo102-/coda $ touch /coda/users/junk
> 
> This simply dereferences the symlink and touches /coda/#rs.users.
> 
> > ilo102-/coda $ echo hello world >>users/junk
> 
> This writes "hello world" into /coda/#rs.users.
> 
> > ilo102-/coda $ ls -l
> > total 0
> > -rw-r--r--  1 1002  nobody  12 Apr 10 15:01 #rs.users
> > lrw-r--r--  1 1002  nobody  10 Apr 10 14:58 users -> #rs.users
> 
> 12 bytes == "hello world\0"
> 
> Just make sure that updateclnt/updatesrv are still running on all
> servers. Also check the timestamps and size of /vice/db/VLDB and
> /vice/db/VRDB.
> 
> Jan
> 

Hi,

Thanks for that, it gave me the vital information to solve the problem.

updateclnt and and updatesrv were running - ps output as follows:

	325  ??  Ss     0:00.53 updatesrv -p /vice/db
	326  ??  Ss     0:00.69 updateclnt -h butch -q coda_udpsrv

These were started from the coda server installed startup script placed
in /usr/local/etc/rc.d.  (Coda installs this as rc.vice, but I renamed
it to vice.sh - otherwise it won't actually run at boottime - at least
not on FreeBSD.)

To cut a long story short there's a problem with the startup script.
Changing the relevant lines as follows sorts the problem out
(originals hashed out):

	#updateclnt -h `cat ${VICE}/db/scm`  -q coda_udpsrv &
	updateclnt -h `cat ${VICE}/db/scm` &

	#updatesrv -p ${VICE}/db &
	updatesrv -p ${VICE} &

The processes then run (in my setup) as:

	325  ??  Ss     0:00.60 updatesrv -p /vice
	326  ??  Ss     0:00.45 updateclnt -h butch

So the startup script has an incorrect directory prefix for updatesrv
and an incorrect service name for updateclnt.

It took me a while to figure this out.  Going by the documentation I
first thought I needed to run updatesrv also with the same -q option
as updateclnt.  However, although it accepted it, it complained that
'-q' was an outdated option.  Also although the latest documentation
I have says that the coda client install places the following entries
in /etc/services:

	coda_opcons     1355/udp                        # Coda opcons
	coda_auth       1357/udp                        # Coda auth
	coda_udpsrv     1359/udp                        # Coda udpsrv
	coda_filesrv    1361/udp                        # Coda filesrv
	coda_venus      1363/udp                        # Coda venus
	coda_backup     1407/tcp                        # coda backup service
	codacon         1423/tcp        venus.cmu       # Coda Console
	coda_aux1       1431/tcp                        # coda auxiliary service
	coda_aux1       1431/udp                        # coda auxiliary service
	coda_aux2       1433/tcp                        # coda auxiliary service
	coda_aux2       1433/udp                        # coda auxiliary service
	coda_aux3       1435/tcp                        # coda auxiliary service
	coda_aux3       1435/udp                        # coda auxiliary service

This is not in fact the case.  The only coda entries in my /etc/services file
are:

	codaauth2	370/tcp
	codaauth2	370/udp
	codasrv         2432/tcp   #codasrv
	codasrv         2432/udp   #codasrv
	codasrv-se      2433/tcp   #codasrv-se
	codasrv-se      2433/udp   #codasrv-se

and most of the additions suggested by the documentation actually conflict
with existing entries!  So I tried adding an extra entry on an arbitrary
port as follows:

	coda_udpsrv     30000/udp       #coda update server

but that didn't work.  Checking the log, however, for updateclnt
showed that the error messages had changed from lines like: 

10:16:14 Fetch failed for 'db/VSGDB' with No such file or directory

to lines like:

10:17:44 Fetch failed for 'db/VSGDB' with RPC2_FAIL (F)

I had thought that even the original meant some kind of protocol
problem, but it was in fact a simple 'looking for the file in
the wrong place' problem.  When I figured that out and guessed
that the additional service entries talked of by the documentation
were probably no longer relevant, I only needed to try running
updateclnt and updatesrv with possible combinations of options
in order to get the right ones.  I then modified the startup
script to match.

It is worth noting that my installation has everthing in the
default places and the startup script is 'as supplied'.

Thanks very much for your help.

Regards,

Dermot

-- 
  Dermot Cassidy, Systems Engineer, A&O Group, Services Engineering,
    Compaq Customer Services, Ballybrit Business Park, Galway, Ireland.
      tel: +353-91-754678 / mailto:dermot.cassidy_at_compaq.com