I guess, the Wierd parameters show in the previous mails are the result of my web browser. Anyways, The reason I was asking if the LWP error is a problem is because I am experiencing some difficulty logging on to the coda server. When I enter "clog adminuser" i get the following error.
Unable to resolve addresses for Coda auth2 servers in realm ........
and upon entering the password i get
Invalid login (RPC2_FAIL (F)).
Does anyone knows where did I go wrong? Thanks
On 11/9/05, Jan Harkes <[EMAIL PROTECTED]> wrote:
On Wed, Nov 09, 2005 at 03:49:51PM -0500, Chong Sein Yeo wrote:
> Hello Guys,
> I am experiencing some difficulty and was wondering if anyone have any clue
> on what may be happening.
>
> I ran
> "venus-setup host1.mydomain.net <http://host1.mydomain.net>,
> host2.mydomain.net <http://host2.mydomain.net> 200000"
???
That's some weird arguments for venus setup. It really only takes 2
arguments,
- the realm name, which is only used by clog/cunlog/cpasswd
- the desired cache size
Venus doesn't ever use the realm name, it is mostly a convenience thing
for the user so that he doesn't have to type,
clog [EMAIL PROTECTED]
That @my.local.realm.name part defaults to the realmname= value in
/etc/coda/venus.conf, which was set by venus-setup. So if that is set to
something it is possible to simply type
clog codausername
The codausername part defaults to the login name of the user who invoked
the clog command, so if the Coda usernames match the usernames on the
local system it is even simpler and the user simply types,
clog
> 14:00:30 starting FSDB scan (8333, 200000) (25, 75, 4)
Interesting, it looks like venus did pick up the right cache size.
> 14:00:30 /coda now mounted.
> ***LWP (0x8116e38): Select returns error: 4
>
> I was just wondering if anyone have any clue on why I am getting that LWP
> Error? Also, i am running Coda version 6.0.14 LWP version 2.1
That error is harmless (EINTR). What happens is that when we try to
mount /coda, the kernel has to ask the venus process what the attributes
of the top level directory are so that it can create the inode object of
the root. But mount is a blocking system call, which would mean that a
single thread would get stuck in the mount, since venus is unable to
handle upcalls while it is blocked waiting for the mount to complete.
Because we don't expect all platforms to have threading, in fact most of
Coda was written before pthreads was even a standard, we fork of a child
process which does the mount("/coda"). The main process can then handle
the upcalls needed to complete the mount process. When the mount
completes the child exits and sends a signal to the parent. The parent
is waiting in select for new upcall messages from the kernel which gets
interrupted, ergo the EINTR error.
Because the mount completed, Coda should be up and running at this
point. You could see if 'ls /coda/testserver.coda.cs.cmu.edu' works.
Jan
--
Warmest Regards,
Yeo Chong Sein
[EMAIL PROTECTED]
