[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:14 glynn]:
 > Replying to [comment:13 mmetz]:
 >
 > > How about avoiding PID altogether and writing 'user at host' to .gislock?
 > That places the burden of determining whether or not the lock is stale
 entirely on the user, as there's no mechanism (even an unreliable one) for
 determining whether the session which created the lock file is alive.
 Writing pid at host would solve the shared-filesystem issue insofar as it
 lets etc/lock know whether the kill() test can be used. If the lock file
 was created by a session running on a different system, there's no
 portable way to determine whether the session is still alive. However,
 displaying the PID and host to the user may allow them to make the
 determination manually.

 Displaying the PID and host to the user assumes that the user knows the
 meaning of PID and host. This is IMHO a false assumption considering the
 current state of linux, mac, and windows, where users usually do not have
 to know or worry about PID's. These are the officially supported OS's, and
 many of their users do not need to be (thus are nowadays probably not)
 familiar with the inner workings of their OS, e.g. PID and what process in
 particular corresponds to a given PID. Apart from the issues mentioned
 earlier that the PID written to .gis_lock does not refer to a PID of the
 current system if the mapset is accessible to multiple users and located
 on a network drive.
 >
 > > 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).
 > It shouldn't remove the lock file. It should only re-write the lock file
 if the PID contained within doesn't match that of an existing process on
 the local system. etc/lock terminates with an exit code of 2 if the
 .gislock file exists and the PID contained within matches an existing
 process, an exit code of 1 if an error occurred (e.g. couldn't create the
 file or couldn't write to it) and an exit code of 0 if the file was
 written successfully.
 >
 > > 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?
 > In practice, stale lock files are sufficiently rare that it's debatable
 whether it's worth the effort of adding a simpler alternative to manually
 deleting the lock file.

 Define practice. What about a windows user starting GRASS with msys and
 just killing the msys terminal at the end, or not even bothering about the
 terminal. I have seen that. I guess that nowadays many GRASS users are
 working on a single-user system with a single-user GRASS database, and for
 these users GRASS must IMHO work 100%. In this case, a lock is probably
 not needed. But there are also other users, e.g. some institutes of public
 administration where many different users access the same GRASS location
 from individual clients, the GRASS location being located on a central
 server. For these, the GRASS locking mechanism must also work, although
 admittedly this is first regulated by file system permission settings.
 Then there are users like e.g. Markus Neteler, Sören Gebbert, and me who
 use GRASS on a cluster system where several hundred nodes may want to
 write to the same mapset at the same time (we have a hack solution for
 that); these users would be found in scientific research environments.
 GRASS makes quite some effort to appease exactly such users (scientists),
 thus these need to be accommodated, too.

 Practice 1: single user single GRASS database
  * best practice would be to ignore a lock and proceed. The question here
 is when a stale lock could occur. A stale lock should be a rare exception
 in this case.
 Practice 2: multiple users, single GRASS database
  * best practice would be to acknowledge a lock and quit (usually this
 would be regulated through write permissions, though). No chance to
 determine if a PID lock is stale.
 Practice 3: single user acting as multiple users from different systems,
 single GRASS database
  * best practice would be to acknowledge a lock and quit (ignore mapset
 write permissions, use lock info only). No chance to determine if a PID
 lock is stale.

 The motivation behind displaying user at host is that most users would know
 their user name and ideally the system (host) where they are currently
 logged in. This (in addition to write permissions) should suffice to let
 the user decide if he wants to try to remove a mapset lock.

 Markus M

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/226#comment:15>
GRASS GIS <http://grass.osgeo.org>