Opened 11 years ago

Last modified 15 months 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 Changed 11 years ago by hamish

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

comment:2 in reply to:  description Changed 11 years ago by glynn

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 Changed 11 years ago by neteler

Milestone: 6.4.07.0.0

comment:4 Changed 6 years ago by neteler

Component: DefaultLibGIS

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

comment:5 Changed 6 years ago by wenzeslaus

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 Changed 6 years ago by neteler

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

comment:7 Changed 4 years ago by martinl

Milestone: 7.0.07.0.5

comment:8 Changed 4 years ago by martinl

Milestone: 7.0.57.3.0

comment:9 Changed 4 years ago by martinl

Milestone: 7.3.07.4.0

Milestone renamed

comment:10 Changed 2 years ago by neteler

Milestone: 7.4.07.4.1

Ticket retargeted after milestone closed

comment:11 Changed 2 years ago by neteler

Milestone: 7.4.17.4.2

comment:12 Changed 22 months ago by martinl

Milestone: 7.4.27.6.0

All enhancement tickets should be assigned to 7.6 milestone.

comment:13 Changed 17 months ago by martinl

Milestone: 7.6.07.6.1

Ticket retargeted after milestone closed

comment:14 Changed 15 months ago by martinl

Milestone: 7.6.17.6.2

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.