[GRASSLIST:9665] Re: gislock on the mapset

[Glynn Clements]

Radim Blazek wrote:

> > > I have a simple question about the gislock file.
> > >
> > > I have the dataset of GRASS in a server and I access to it from several
> > > computers link in a network.
> > > I saw that if I try to access two times on the same mapset using the same user
> > > from the same computer the file gislock works well and GRASS say:
> > >
> > > "user is currently running GRASS in selected mapset. Concurrent use not
> > > allowed."
> > >
> > > But if I try to access two times on the same mapset using the same user from
> > > an OTHER computer the file gislock does not work and I can acces with the
> > > possibility to make damages.
> > >
> > > Is it possible or I make some errors?
> >
> > Which version of GRASS? 5.x or 6.x?
> >
> > 5.x puts the lock file in the user's home directory. The requirement
> > that you have to own the active mapset prevents you from starting two
> > sessions on the same mapset from the same host, but doesn't help if
> > the mapset is shared between hosts.
> >
> > 6.x puts the lockfile in the mapset directory, so it should prevent
> > the scenario which you describe. If it doesn't, that's a bug.
> 
> Unfortunately no because it checks the PID.
> It is feature not bug, locking works only on one machine.
> This is inherited from 5.0, I dont see big difference.
> Do you have idea how to improve that so that it works over network?

1. Don't check the PID. But then a stale lockfile has to be removed
manually.

2. Use a kernel lock (flock/lock/fcntl). But that requires an NFS
implementation which supports locking (nfs.lockd).

The easiest of those two would be to provide an option for 1. 
Installations for single-user systems would contine to check the PID,
while installations intending to allow networked access would skip the
check.

-- 
Glynn Clements <glynn at gclements.plus.com>