gripes about .grassrc/env vars/locks/permissions

Malcolm Williamson malcolm at cast.uark.edu
Mon Jul 12 10:29:05 EDT 1993


Darrell McCauley writes:
> 
> I've run into a problem where if I run (concurrently) grass on two
> separate machines and separate databases, things get screwed up ($HOME
> and my data are both on the same filesystem, which is NFS mounted on both
> machines).  For example, programs like g.list seem to consult the
(Lines deleted)

I'm probably not your typical GRASS user (is there such a thing?!), but I 
frequently find it desirable to run concurrent GRASS sessions in different
databases/Locations/Mapsets. It seems like I spend an awful lot of time
trying to outsmart GRASS...

> 
> Something about this whole locking scheme with world writable
> directories doesn't sit so well with me. :-( 
> It doesn't go over too well with system administrators here
> (where any one of 10000+ users could write to these directories!!!)
> 
> Comments?  

I always wondered why our system administrators make faces whenever I mention
GRASS!!

> 
> If data integrity is the primary concern, WHAT ARE THE DRAWBACKS TO
> INCORPORATING A NETWORK LICENSING SCHEME with only one license per
> mapset? Concurrent grass sessions could be allowed by the same users,
> but noone would be allowed to work on the same MAPSET at the same
> time. Granted, sometimes these things are a pain to keep running, but
> if it was designed so that it was fileserver dependent, that is, ask
> the daemon from which the data is mounted for permission, problems
> would be minimized.  (After all, if that server is down, you cannot
> get to your data anyway). Only one daemon per server should be needed
> to keep track of which mapsets were being used.  Just as long as it
> was dependable.
> 
> Sorry to rattle on, but just a little tired of having
> to justify some of these things (to others and myself).
> 
> --Darrell
> 

I'm no Unix guru, but this approach sounds very reasonable to me. Perhaps the
original structure could be retained for stand-alone applications. I would
like to see something like this in future releases of GRASS (although I
wouldn't give it quite the priority of "Floating Point Now!").

-- 
Malcolm D. Williamson - Research Assistant       E-mail: malcolm at cast.uark.edu
Center for Advanced Spatial Technologies      Telephone: (501) 575-6159
Ozark Rm. 12                                        Fax: (501) 575-3846 
University of Arkansas              
Fayetteville, AR 72701



More information about the grass-user mailing list