[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:17 mmetz]:
 > 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.

 The main requirement for this is that the lock file needs to contain both
 the host and the PID. As for the check: if the host is not the local
 system, the status is unknown, otherwise the lock file is considered live
 if the PID exists and stale otherwise. False positives can be reduced by
 testing for the PID twice with a delay in between.

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

 I should have said "possibly-stale lock file". If it's definitely stale,
 there's no problem deleting it, but we don't actually know that with the
 current code. If we don't know whether it's stale (because it was created
 on a different host, or because we don't have a Windows equivalent for the
 kill() test), the determination will need to be made manually by someone
 who understands what "host" and "PID" mean.

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

 I'm talking about the case where the lock program is unable to reliably
 determine stale-ness and has to defer to the user.

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

 The PID refers to the GRASS session, specifically to the process running
 the script which starts the GRASS session and persists for the lifetime of
 the session. There isn't any practical alternative. Process groups won't
 work, as the shell typically creates a new process group for each command
 or pipeline. The (Unix) session ID (SID) would be more accurate, but
 there's no way to tell whether a session exists other than by parsing the
 output from "ps" (both the format and the flags required to list the SID
 tend to be platform-specific).

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

 Even if the session which created the lock file is idle, there's no
 guarantee that the user won't subsequently "revive" it, so it isn't safe
 to override the lock file so long as that session exists.

 Having the PID in the lock file is the only way that an "obviously stale"
 lock file can be detected and overridden automatically. Without that, any
 lock file must be assumed to be live, with any override requiring user
 involvement.

 Storing the user in the lock file is harmless but redundant. The user
 stored in the lock file will always be the user who owns both the mapset
 directory and the .gislock file. The start-up code won't let you select a
 mapset which you do not own as the current mapset.

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