#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@host instead of user@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@host is, particularly in complex environments, more
reliable that PID@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>