|
|
 Up |
|
|
  |
Author: François CerbelleFrançois Cerbelle
Date: Jan 18, 2007 01:46
On Mer 17 janvier 2007 23:30, Jan Harkes a =E9crit :
> Ah, the CML is owned by the user that made the changes, the error log
> file (/usr/coda/etc/console or /var/log/coda/venus.err) may contain som=
e
> indication about that fact,
>
> Reintegrate pending tokens for uid =3D
>
I am not at home and I can not test what you told me, but I can give some
extra info :
Yes there is such a line (vol u.natalia and uid 1001). But the cache file=
s
belongs to root:staff and event if I connect with the 1001 uid (natalia),
venus tell me it reintegrate changes, but nothing happens. No CML are
reintegrated, no network transfert occurs and the same message will
happen, later.
|
| Show full article (3.14Kb) |
|
| |
no comments
|
|
|
Author: Jan HarkesJan Harkes
Date: Jan 17, 2007 09:30
On Wed, Jan 17, 2007 at 03:30:58PM +0100, Achim Stumpf wrote:
> [root@clusty1 ~]# purgevol_rep --kill /
> awk: $1 !~ /^/$/ { print }
> awk: ^ syntax error
> awk: $1 !~ /^/$/ { print }
> awk: ^ unterminated regexp
Sigh, I clearly don't purge data often enough.
> VLDB created. Search lengths: RO 0, RW 0, BK 0.
...
> 15:24:50 VLDB_Lookup: cannot find "/"
Ok, that is good. I guess the volume replica was successfully removed
from the 'volume location database'. So what went wrong was removing the
volume from the 'replication database'.
But that is pretty easy to fix,
- on your SCM edit /vice/db/VRList and remove the line that starts with /
- Then run 'volutil makevrdb /vice/db/VRList'
Jan
|
| |
|
| |
no comments
|
|
|
Author: Achim StumpfAchim Stumpf
Date: Jan 17, 2007 06:36
Hi,
On my client:
[root@clusty4 ~]# cfs whereis /coda/mytest.de
clusty1.mytest.de
This volume runs only on one server.
Jan Harkes wrote:
> If it only has a single replica, then the most reliable method is to
> remove the existing root volume and create a new one,
>
> purgevol_rep /
>
I got:
[root@clusty1 ~]# purgevol_rep /
Only testing, use 'purgevol_rep --kill /' to really purge the volume
Don't forget we were only testing
use 'purgevol_rep --kill /' to really purge the volume
|
| Show full article (2.72Kb) |
|
no comments
|
|
|
Author: Jan HarkesJan Harkes
Date: Jan 17, 2007 05:38
On Tue, Jan 16, 2007 at 12:40:40PM +0100, Achim Stumpf wrote:
> [root@clusty4 ~]# cfs listvol /coda/mytest.de/
> Status of volume 7f000000 (2130706432) named "/"
> Volume type is ReadWrite
> Connection State is Connected
> Reintegration age: 4294967295 sec, hogtime 4294967.295 sec
> Minimum quota is 0, maximum quota is unlimited
> Current blocks used are 2
> The partition has 8191888 blocks available out of 8211208
>
> I stopped with your advice after the client setup. I haven't created any
> volumes. So I wonder now, if the /coda/mytest.de/ is now replicated over
> those three servers or not?
That is simple,
cfs whereis /coda/mytest.de
I think that the default setup created only a single replica, since the
volume got created when we set up the SCM before we had the other
servers up.
|
| Show full article (2.15Kb) |
|
no comments
|
|
|
Author: Jan HarkesJan Harkes
Date: Jan 17, 2007 05:24
On Wed, Jan 17, 2007 at 10:46:37AM +0000, Paulo Andre wrote:
> It did help. It's now working, even if I'm still flabbergasted as to
> why it was looking for the old address instead of the current one.
> But, following your instructions, it definitely looked like a name
> resolution problem or something along those lines.
Good thing it works now. What worries me is that venus died like that.
It shouldn't be doing that and just return a symlink that points at
nothing to the user.
Jan
|
| |
|
no comments
|
|
|
Author: Paulo AndrePaulo Andre
Date: Jan 16, 2007 07:40
From running venus in conjunction with 'codacon', I've been able to
learn that the problem seems to be lying on the fact that venus is
trying to contact an host that doesn't exist anymore. This is
suspicious, because it seems to be a residue from a previous
installation. However, I've wiped everything I could think of in the
client and start with a clean slate but still it tries to connect to
that old address. Where can this be hidden?
Cheers,
P.
On Jan 16, 2007, at 2:25 PM, Paulo Andre wrote:
> Hi,
>
> I've been trying to get a coda server and client to happily talk to
> each other but unfortunately it's been proving difficult.
> Everything seems to be installed OK on both machines, and...
|
| Show full article (1.92Kb) |
|
no comments
|
|
|
Author: Paulo AndrePaulo Andre
Date: Jan 16, 2007 07:38
Hi,
I've been trying to get a coda server and client to happily talk to
each other but unfortunately it's been proving difficult. Everything
seems to be installed OK on both machines, and I can 'clog' just fine
from the client into the server. But then when I try to read /coda it
just hangs for about a minute and bombs out with:
prla@citidesk1:/var/lib/coda/cache$ ls /coda
ls: /coda/193.137.121.129: No such device
With 193.137.121.129 being the coda server. A quick glance at /var/
log/messages on the client tells me that:
|
| Show full article (1.34Kb) |
|
no comments
|
|
|
|
|
|
Author: Jan HarkesJan Harkes
Date: Jan 10, 2007 12:29
On Wed, Jan 10, 2007 at 11:40:26AM +0100, Achim Stumpf wrote:
> Have you guys any further advice? Should i reinstall the whole thing?
> Somehow i am completely stuck here...
>
> As we can see in my last mail volutil.tk has the same values as shown by
> od.
I saw that. So the failure to bind to the second server isn't an
authentication issue. I can only think of a couple of reasons why we get
a no-binding result.
1) there is no Coda server running on clusty2.
2) for some reason DNS or /etc/hosts is messed up and we end up trying
to connect to some other machine that isn't running a Coda server.
3) There is a firewall on clusty2 that is dropping/rejecting incoming
UDP packets to the codaserver port (2432/udp).
Jan
|
| |
|
no comments
|
|
|
|
|
