[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 glynn):

 Replying to [comment:15 mmetz]:

 > Displaying the PID and host to the user assumes that the user knows the
 meaning of PID and host.

 If they don't, they probably can't safely deal with a stale lock file.

 On an unshared filesystem, the automatic resoluation via the kill() test
 will usually work. The exceptions are where the PID has since been re-used
 for an unrelated process (false positive), or if the shell itself has been
 killed but child processes are still running (false negative). If they're
 using a shared filessytem, there's probably some form of technical support
 available.

 > 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.

 If the session on that terminal is still "working" (i.e. not just waiting
 for the next command), it's fairly important that they don't just start up
 another session using the same mapset.

 > Practice 1: single user single GRASS database
 >  * best practice would be to ignore a lock and proceed.

 Note that this could result in a corrupted database. I don't know how
 likely it is practice, i.e. whether it's common to have long-running
 background jobs on Windows systems.

 > 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.

 They really need the PID in order to make that determination. Some people
 have jobs which run for days. In a complex environment (where users have
 accounts on several multi-user systems), it's not inconceivable that
 someone can forget which jobs are running on which systems using which
 mapsets.

 In normal use, stale lock files shouldn't occur, so the presumption should
 be that any existing lock file isn't stale. That presumption may be
 overridden in the presence of additional evidence; e.g. if the PID
 contained in the lock file doesn't refer to an existing process
 (particularly if the lock file also contains a host and the host is the
 local system), that tends to indicate staleness (the case where the shell
 has terminated but child processes survive is rather hard to detect).

 The solution to the problems with the existing mechanism should be to fix
 it, e.g. by adding a Windows equivalent of the PID test, and adding the
 host to the PID file. Rather than assuming that a lock file is stale
 solely because the assumption is convenient, regardless of its accuracy.

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