[GRASS-user] .gislock problem

[Markus Neteler]

On Mon, Jul 7, 2008 at 3:13 PM, Christian Braun
<christian.braun at tudor.lu> wrote:
> Hi guys,
>
> I am a colleague of Jessica who posted before this:
> http://www.nabble.com/GRASS-BATCH-JOBS-to17470510.html#a17475609
>
> We are using GRASS in an interactive website to calculate on-the-fly maps
> which are then presented to the user. It is not really a WebGIS-Client and
> it doesn't aim to be one. We tested also pyWPS but the script was there
> before and it was to complicated to adept the needs of pyWPS.
>
> As we are running GRASS in a "multiuser" web environment we need a
> workaround to treat different contemporary users. We decided then to create
> a bash workaround to solve this:
>
> First we encountered that GRASS in batchmode is not writing the .gislock
> file, but it writes in normal interactive mode with the same user used.

See below...

> In the next step we tested if we can then run two instances of the same
> script in the same mapset and it worked.

you can, but it's risky if you touch resolution and region extent.

> We can not find the issue why this is working. Currently we are in the
> testing phase and the project will be online soon, so we have to be sure
> what GRASS is doing with .gislock and all related staff to avoid problems
> with concurrent users.

Best is to run concurrent user sin different mapsets.

> Currently we are using Ubuntu 7.04 with packages of Jachym (GRASS 6.2).
> These will be updated to Hardy and GRASS 6.3 before release.

If you check the GRASS 6.3.0 announcement:
http://grass.osgeo.org/announces/announce_grass630.html
"Batch mode for launching GRASS for non-interactive processing tasks"

... it's well worth to update. I/we have added much simplification in 6.3.0
since I needed to process MODIS maps in parallel on a cluster. But
these changes weren't backported to 6.2 (too complicated).

Markus