Opened 15 years ago

Last modified 5 years ago

#446 new enhancement

put user and machine name into .gislock file

Reported by: benducke Owned by: grass-dev@…
Priority: minor Milestone: 7.6.2
Component: LibGIS Version: svn-trunk
Keywords: locking, .gislock Cc:
CPU: Unspecified Platform: All

Description

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(?).

Change History (14)

comment:1 by hamish, 15 years ago

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

in reply to:  description comment:2 by glynn, 15 years ago

Replying to 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.

comment:3 by neteler, 15 years ago

Milestone: 6.4.07.0.0

comment:4 by neteler, 10 years ago

Component: DefaultLibGIS

Did we miss this train again for GRASS 7.x?

comment:5 by wenzeslaus, 10 years ago

According to 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?

comment:6 by neteler, 9 years ago

Let's get it implemented now if we want to see it in GRASS 7... the last beta is being prepared.

comment:7 by martinl, 8 years ago

Milestone: 7.0.07.0.5

comment:8 by martinl, 8 years ago

Milestone: 7.0.57.3.0

comment:9 by martinl, 7 years ago

Milestone: 7.3.07.4.0

Milestone renamed

comment:10 by neteler, 6 years ago

Milestone: 7.4.07.4.1

Ticket retargeted after milestone closed

comment:11 by neteler, 6 years ago

Milestone: 7.4.17.4.2

comment:12 by martinl, 5 years ago

Milestone: 7.4.27.6.0

All enhancement tickets should be assigned to 7.6 milestone.

comment:13 by martinl, 5 years ago

Milestone: 7.6.07.6.1

Ticket retargeted after milestone closed

comment:14 by martinl, 5 years ago

Milestone: 7.6.17.6.2

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.