#226: WinGRASS fails to create .gislock opening a mapset
----------------------------+-----------------------------------------------
Reporter: msieczka | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.2
Component: Default | Version: svn-develbranch6
Keywords: wingrass, qgis | Platform: MSWindows XP
Cpu: All |
----------------------------+-----------------------------------------------
Comment(by mmetz):
Replying to [comment:12 glynn]:
> Replying to [comment:11 mmetz]:
>
> The existing code won't work in its entirety on Windows. As Windows
systems aren't generally multi-user, simply ignoring the entire locking
issue was the easiest solution.
But GRASS databases and locations are multi-user by design, the system
used to access a mapset may or may not be single-user, that would not
matter if the GRASS database is somewhere on a network.
>
> > Under Linux, assume the following scenario: a group of people are
working from different machines on the same location, different mapsets.
The location is on a network drive accessible by everyone. Now g.mapset
mapset=othermapset using lock (GIS_LOCK) checks if it could kill the pid
written in .gislock. But if the pid in .gislock has been written by a
different machine/system, then the pid in .gislock has nothing to do with
the pid's available to lock, and the kill()-test is complete moot. Right?
>
> The purpose of the kill() test is to check whether the .gislock file is
"stale", i.e. whether the session which created the .gislock file
terminated without removing it. If kill() fails with ESRCH, the PID stored
in the .gislock file doesn't refer to an existing process on the local
system, so the lock is assumed to be stale and is ignored. This test isn't
particularly reliable; it will consider the lock as stale if it was
created by a session on another machine, even if that session is still
alive, and will consider the lock as alive if the session has terminated
but its PID is now used by another process.
Sounds like using PID is not a reliable solution, this can easily result
in both false positives and false negatives.
>
> > Therefore I would suggest to skip the find_process() step and assume
that a mapset is locked as long as the file .gislock exists.
>
> That would avoid the issue with the lock file being considered stale due
to having been created on a different system. OTOH, it would require stale
lock files to always be removed manually. If that is considered a problem,
writing a hostname along with the PID would solve the first issue without
abandoning automatic removal on non-shared filesystems.
I don't see an easy way for reliable automated handling based on GIS_LOCK
and the PID in .gis_lock, because a lock may be removed even though it is
alive or be not removed even though it is stale. How about avoiding PID
altogether and writing 'user@host' to .gislock? Currently, in trunk, the
wxGUI asks at startup if an existing lock should really, really be
removed. Starting trunk in text mode silently removes any gislock (needs
to be fixed). How about a new flag for yes-I-know_what-I'm-doing to try to
force remove an existing lock both at startup and for g.mapset?
Markus M
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/226#comment:13>
GRASS GIS <http://grass.osgeo.org>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
