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

 My main concern is that valid lock files are regarded as stale lock files.
 Since it seems not to be trivial to distinguish between valid and stale
 lock files, I would opt to keep the lock file and deny access to the
 mapset in question if the state of the lock file can not be safely
 determined. The check for the state of a lock file should return one of
 three answers: is valid, can't say, is stale. The lock file is (should be)
 removed if stale, if its status is unknown, user-interaction is probably
 the only option.

 Replying to [comment:16 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.

 ??? There is no danger in removing 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.

 I'm afraid that's beyond my knowledge. What form of technical support do
 you have in mind that could be used by the lock executable?
 >
 > > 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.

 That scenario was a bit provocative, but unfortunately I have seen it
 happening. In this case I would go for a check including the host name.
 >
 > > 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.
 OK. If in doubt, assume a valid lock.
 >
 > > 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.
 I assume that on multi-user systems, user names are unique. In a complex
 environment, host names should also be unique. PIDs however are not
 unique, or at least not fail-safe as you have pointed out earlier. A new
 process may be started with the same PID as in the valid or stale lock
 file.

 Note that the PID in the lock file does not refer to the (long running)
 job they are currently busy with. The PID in the lock file refers to the
 instance of init.sh for GRASS 6 and grass.py for GRASS 7. That is, a user
 may do nothing while logged into a mapset, but as long as he/she is logged
 in, it's blocked for others. A consequence of the modular design of GRASS,
 I guess. As long as you are logged in to a given mapset, this is yours
 only, no matter if you actually do something there or not.
 >
 > 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).

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

 Sorry for being stubborn. You have provided only one argument for the
 usage of PID at host instead of user at host: I argue that the PID does not say
 anything about long-running jobs, it may as well be an abandoned GRASS
 session. I would, as dangerous as it may be, offer the user the option to
 override the lock if there are doubts whether the lock is valid. And I
 think that user at host is, particularly in complex environments, more
 reliable that PID at host.

 Markus M

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