[GRASS-dev] Re: [GRASS GIS] #226: WinGRASS fails to create .gislock
opening a mapset
trac at osgeo.org
Fri Dec 16 15:37:24 EST 2011
#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 |
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
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
> > 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.
Ticket URL: <http://trac.osgeo.org/grass/ticket/226#comment:15>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev