On Mon, 14 Jul 1997 thoth_at_purplefrog.com wrote:

>   So, I hear the testserver has been properly configured, so I connect,
> successfully!

Congratulations!

>   I start poking around and quickly:
> 
>  frop:44 $ ls -l /coda/playground/
> ls: /coda/playground/banana: I/O error

This is OK -- at least, the client is behaving correctly.  'banana' is
like a dangling pointer of some kind on the server.

> total 13
> -rw-rw-rw-   1 65435    65534          10 Jul  3 19:35 and indeed another one
> -rw-rw-rw-   1 65435    65534          10 Jul  3 19:35 another unimportant file
> drwxr-xr-x   2 65435    65534        2048 Jun 24 03:51 catfish
> -rw-rw-rw-   1 65435    65534          10 Jul  3 19:35 michael with Windows 95
> drwxr-xr-x   3 65435    65534        2048 Jun  9 21:21 peter-braam
> drwxr-xr-x   2 65435    65534        2048 May 30 14:56 sand_pants
> drwxrwxr-x   2 65435    65534        2048 May 17 22:01 sopwith
> drwxr-xr-x   3 65435    65534        2048 Jul 14 12:58 thoth
> 
>   banana?
> 
>   Anyway, I create a directory (as you can see) and put some source to run a
> build in.  I accidentally type make as root (when I had extracted all the files
> as "thoth") and it hangs.  I thought it was a caching issue until I interrupted
> it and typed make as thoth.  It built, not blazingly fast, but not slow either.
> rpm -q -l coda-client lets me know there's a coda-cache command so I turn on
> caching and get a 33% decrease in build time.
> 
>   So I decide to get back to that wacky root hang thing.
> 
> [root_at_frop netpipes4.0]# echo blah | strace dd of=shit
> 
> ...
> 
> stat("/usr/local/share/locale/C/libc.cat", 0xbffff4cc) = -1 ENOENT (No such file or directory)
> open("shit", O_RDWR|O_CREAT|O_TRUNC, 0666 <unfinished ...>
> 
>   Strange.  I would have expected at least an error return code.  (I let it
> block for several minutes before I finally interrupted it).
> 
> 
> 
> 
>   Right now I seem to be hung.  there's quite a bit of stuff showing up in the
> log, and pwd does not complete.
> 
> brk(0x804a22c)                          = 0x804a22c
> brk(0x804b000)                          = 0x804b000
> lstat(".", 
> 
> 
> [ X(00) : 0000 : 13:37:45 ] DispatchWorker: out of workers (max 5), queueing message

I think Peter has a handle on these hanging probems that end up with Venus
running out of worker threads.  I was seeing similar phenomena when I was
at CMU last week, working on a different port.  The problem may well have
to do with a design glitch left over from Coda's mach-centric roots: some
Venus<-->Vice RPCs exchange errno error numbers using the native
platform's errno.h rather than translating into a canonical set.  Of
course, errnos differ from platform to platform, and so it is possible for
Venus and Vice to get confused if they are running on different OSes.  (If
you ever see this problem running the Linux client against a Linux server,
please let us know.)

Needless to say, this will get fixed.

>  frop:9 $ ps auxww | grep venus
> root     19516  0.7  9.4  7056  5996  ?  S   12:52   0:20 venus -init 
> root     19521  0.0  0.4   872   312  ?  S   12:52   0:00 tail +0f /usr/coda/venus.cache/venus.log 
> root     19527  0.0  0.0     0     0  ?  Z   12:52   0:00 (venus <zombie>)
> thoth    20109  0.0  0.5   964   336  ?  S   13:39   0:00 grep venus 

Other than the fact that venus should reap the child that does the
mount(2), this looks OK.

Michael