Thu, May 17 2001
14:48:10
|
|
Request created by guest
|
|
Subject: Grass5 and NFS
Platform: Linux/Intel
Linux distro: RedHat
linux cpu: AMD (K6, ...)
Xwindows version: Xfree 4.0.x
Xwindows manager: wmaker
grass binary for platform: I compiled the sources myself
grass sources source: no, I got a source code package from the server, 5beta1
c compiler name: gcc
at the command d.mon start=x0 it asnwers that it can't complite the locking procedure.
Indeed the dir for locking is exported by nfs and it doesn't have the permision
to write on it.
So maybe there is a env-variable to change in order to make grass lock at a dir
with write permision.
chmod -R 1777 /usr/local/grass5/locks/
just done but nothin change.
Arjuna |
|
Tue, May 22 2001
18:54:21
|
|
Mail sent by guest
|
|
An environment variable is probably a bad idea; in order for lock
files to work, all processes have to use the same path. With an
environment variable, this may not happen.
It may be worth making it a compile-time option, though.
BTW: what is this directory used for?
--
Glynn Clements <glynn.clements@virgin.net>
|
|
Mon, Jul 2 2001
21:35:51
|
|
Comments added by guest
|
|
I suspected this might be a problem a while back.
In the GRASS 5.0 code base, I submitted a preliminary method
for setting up a per-user directory $HOME/.grass5/ where things
like configuration files and the socket files for monitors could
live. It works, but will take recompilation of GRASS sources
and some minor modifications to src/libs/gis/Gmakefile,
src/libs/gis/unix_socks.c where the source file that needs to be
compiled is src/libs/gis/user_config.c. There should be some
comments in both "unix_socks.c" and "user_config.c" about how to
get the conditional compilation done right.
I'll mention it again on the grass5 list, see if others are amenable
to moving things to $HOME/.grass5. It was never resolved after the
last time I brought it up.
Eric G. Miller <egm2@jps.net>
|
|
Thu, Sep 6 2001
15:07:12
|
|
Comments added by mneteler
|
|
CC from GRASS5 list:
> What was the NFS Problem? It works here with Linux and IRIX as NFS
> Server and client. Its hard to say something if i do not know the OS and
> the exact problem.
The problem (bug #269) is that $GISBASE/locks needs to be writable,
which means that $GISBASE can't reside on a read-only export.
It isn't likely to be a widespread problem. I would assume that it can
be worked around by making $GISBASE/locks a symlink to a directory on
a writable export.
The locking mechanism just won't work without a shared writable
directory. Changing the locking mechanism probably isn't practical if
you want to release soon.
--
Glynn Clements <glynn.clements@virgin.net>
|
|
Tue, Oct 9 2001
09:44:32
|
|
Mail sent by mneteler
|
|
Hi,
concerning GRASS and NFS: the current CVS version contains a fix
for NFS now. Eventually wait for the next CVS snapshot which contains
the fix.
Markus Neteler
Date: Tue, 9 Oct 2001 00:28:32 -0700
From: "Eric G. Miller" <egm2@jps.net>
I have committed a change in the CVS sources that will hopefully
make this problem disappear for everyone. You can grab a copy
of the grass/src/libes/gis/unix_socks.c file from the web-cvs
interface and rebuild GRASS using it rather than going through
the changes I outlined earlier. You'd only need to replace
the one file in your copy of the sources...
|
|
Tue, Oct 9 2001
09:44:43
|
|
Status changed to resolved by mneteler
|
|