[Feat] Switch to mapsets with stale locks automatically

[wenzeslaus]

Background

When a GRASS session is terminated in some bad way (computer crash, kill signal), it leaves the mapset locked. The lock file is stale. These stale lock files are identified by heuristic in etc/lock (lib/init/lock.c) based on PID saved to the lock file. If process of the given PID exists, the lock file is considered valid. If there is no process with the given PID, the lock file is considered stale and the mapset is thus available for use, i.e., the locking acts as if there would be no lock and locks the mapset. The system is not perfect as PIDs get recycled, but since it simply considers the mapset in use, no further assumptions are done and the decision is passed to the user.

What happens

If there is an stale lock file in a mapset, the grass command with an explicit mapset path in the command line uses that mapset automatically, i.e., without a need to use -f.

On the other hand, using the last used mapset, i.e., running the command without parameters, and switching in the GUI itself, is doing additional checks before calling etc/lock or g.mapset (which in turn calls etc/lock), so the automatic unlocking of mapsets with stale locks does not happen because the checks don't replicate the PID behavior of lib/init/lock.c.

What should happen instead

It would be nice if all starts and switches would use the automatic unlocking.

Or would it be? In GUI, you then see "(in use)" next to a mapset, you switch to it and that's what happens regardless of the "(in use)" which was there.

Opinions?

Additional info

To test it, you need two terminals to open (or attempt to open) two GRASS sessions with the grass command and the following command for getting the PID to kill:

cat ~/grassdata/nc_basic_spm_grass7/user1/.gislock | dd ibs=1 2>/dev/null | od -td4

Note 1: Locking is disabled on Windows. (I don't have a reference for the reason, though.)

Note 2: If it is not clear from the description, the code for this is spread over g.mapset, etc/lock, the main GRASS executable (grass.py), wxGUI, and the grass Python package.

[neteler]

Note 1: Locking is disabled on Windows. (I don't have a reference for the reason, though.)

I searched for it:

• grass-dev: introduction of Windows support:
  • [GRASS5] GRASS for Windows: https://lists.osgeo.org/pipermail/grass-dev/2005-November/020279.html
• source code: commit of Windows warning "Locking is not supported on Windows!":
  • OSGeo/grass-legacy@6015d91
• later discussion about reasons:
  • [GRASS-dev] Locking is not supported on Windows (see entire thread):
    • https://lists.osgeo.org/pipermail/grass-dev/2008-May/038037.html
    • https://lists.osgeo.org/pipermail/grass-dev/2008-May/038125.html

[wenzeslaus]

Glynn Clements on Thu May 22 06:33:32 EDT 2008:

One option would be to make etc/lock provide more detail if it fails
due to the lock being present, including the pathname of the lock
file, and a recommendation to manually delete it if you are certain
that no other GRASS sessions exist.

Another option is to change g.mapset to simply skip the locking step
on Windows. A user starts multiple sessions at their own risk.

Making locking actually work would require knowing how to check the
status of a process on Windows.

So it seems that the number one reason the locking is not on Windows is that there was no way to deal with the stale lock files. (At least according to Glynn Clements. The change for Windows was done by Radim Blazek.)

While the "option 2: skip the locking step on Windows" was implemented at that time, in the mean time, we implemented "option 1: provide more detail if locking fails" and the feature of automatic removal of stale locks was for forgotten.