put user and machine name into .gislock file

[landam]

Reported by benducke on 20 Jan 2009 15:54 UTC If a .gislock file gets created for a user, then it might be a good idea to store that user's current login name and machine name in the file. That way, external GUIs that encounter a lockfile when trying to log a user into a mapset will be able to output a more specific error message, including the lockfile creator's identity, giving the user a better clue as to whether the lockfile can be safely deleted or not.

Not sure what version of GRASS this could go into, but it seems to me it would not affect any of the current functionality(?).

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/446

[landam]

Comment by hamish on 20 Jan 2009 20:26 UTC there is a good chance that the lock file was created by you on the local machine. so perhaps it would be good to also log the lock file creation time as an indicator of how stale the file is. (or check file creation time if that is portable)

I am a bit unsure if this should really be targeted for grass 6.4 or only go into grass 7. I understand waiting for grass 7 is unpleasant for QGIS, but we must protect the stable branch.... if for grass64 we must ensure backwards compatibility with other grass 6.[0-3].

Hamish

[landam]

Comment by glynn on 21 Jan 2009 12:56 UTC Replying to [ticket:446 benducke]:

If a .gislock file gets created for a user, then it might be a good idea to store that user's current login name and machine name in the file. That way, external GUIs that encounter a lockfile when trying to log a user into a mapset will be able to output a more specific error message, including the lockfile creator's identity, giving the user a better clue as to whether the lockfile can be safely deleted or not.

The machine name should go into the file. At present, etc/lock reads the PID and checks whether the process is still running. Obviously, this only works if the creator process is running on the same system as the checking process.

Also, the current format is an "int" in the platform's native format, so you can't even report the PID correctly if it was written using a different byte order (or sizeof(int)).

lib/init/lock.c should at least check that PID is positive before checking for existence.

Not sure what version of GRASS this could go into, but it seems to me it would not affect any of the current functionality(?).

It can't go into 6.x, as existing versions of GRASS won't understand the new format, and in the case where the database is shared via NFS, you can't assume that all systems are using the same version of GRASS.

[landam]

Modified by neteler on 21 Jan 2009 16:54 UTC

[landam]

Comment by neteler on 20 Apr 2014 19:27 UTC Did we miss this train again for GRASS 7.x?

[landam]

Comment by wenzeslaus on 21 Apr 2014 01:31 UTC According to http://semver.org/ semantic versioning, ''pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version,'' And we are not yet released 7.x. So, if we are still adding minor features to release branch, the rules allows us to add this if it is not too dangerous (I cannot tell) or it is very important.

Is somebody able to implement this?

[landam]

Comment by neteler on 8 Nov 2014 21:38 UTC Let's get it implemented now if we want to see it in GRASS 7... the last beta is being prepared.

[landam]

Modified by @landam on 12 May 2016 06:44 UTC

[landam]

Modified by @landam on 23 Aug 2016 11:42 UTC

[landam]

Comment by @landam on 27 Aug 2016 13:42 UTC Milestone renamed

[landam]

Comment by neteler on 26 Jan 2018 11:40 UTC Ticket retargeted after milestone closed

[landam]

Modified by neteler on 12 Jun 2018 20:48 UTC

[landam]

Comment by @landam on 25 Sep 2018 16:53 UTC All enhancement tickets should be assigned to 7.6 milestone.

[landam]

Comment by @landam on 25 Jan 2019 21:08 UTC Ticket retargeted after milestone closed