[GRASS-dev] Re: [GRASS GIS] #226: WinGRASS fails to create .gislock
opening a mapset
GRASS GIS
trac at osgeo.org
Fri Dec 16 14:13:36 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 |
----------------------------+-----------------------------------------------
Comment(by 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
determination manually.
> 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
written successfully.
> 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.
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/226#comment:14>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list