[GRASS-user] Multiple `r.proj` requests on the same raster map(s)
neteler at osgeo.org
Sat Feb 24 14:00:32 PST 2018
On Sat, Feb 24, 2018 at 10:31 PM, Markus Metz
<markus.metz.giswork at gmail.com> wrote:
> On Sat, Feb 24, 2018 at 10:06 PM, Nikos Alexandris <nik at nikosalexandris.net>
>> * Markus Metz <markus.metz.giswork at gmail.com> [2018-02-24 21:39:40 +0100]:
>>> On Sat, Feb 24, 2018 at 9:25 PM, Nikos Alexandris
>>> <nik at nikosalexandris.net>
>> Looking at jobs logs, I read lots of ".gislock" lines.
>> It might be some permission related issue. I partially operated directly
>> (with my user-id) on many Locations.
>> The operateor of the scheduler, has naturally, another user-id. I wonder
>> if I should apply GRASS_SKIP_MAPSET_OWNER_CHECK=1 everywhere.
> No, you need to run each process in a unique temporary mapset.
Yes, only that works. Be sure to have a sufficiently long random
string to be used as temporary mapset name.
You can for example the outout of
and add the machine name to it (and maybe the current time stamp
cleaned for special chars) to avoid race conditions if you use a
shared network storage.
> Once you have
> the final result, change the current mapset with g.mapset to the common
> mapset where final results should stored and copy the final result from the
> temporary mapset to the current mapset (the mapset to hold the final
(we have processed terabytes of LST data like this :-)
> Alternatively/additionally, don't use the script grassXY to start a GRASS
> session, instead define the GRASS environment with custom scripts (one for
> the GRASS version to use, one for the database/location/mapset to use). This
> avoids race conditions on a HPC system. A unique temporary mapset for each
> process helps to avoid all sorts of concurrent access problems.
> Markus M
Let's expand this Wiki section a bit with our findings (I'll try to
find my notes):
More information about the grass-user