[GRASS-dev] Re: [GRASS GIS] #226: WinGRASS fails to create .gislock opening a mapset

[GRASS GIS]

#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 at 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>