(Illustration by Gaich Muramatsu)
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.comReceived on 2001-04-11 06:53:58