[MapProxy] Error: No such file or directory: .lck

[Anne Blankert]

Hallo Anna,

did you check that directory
/var/www/mapproxy/cache_data/tile_locks/

actually exists and is writeable by the mapproxy user?

You can specify the location of the lock directory in you yaml file, for
instance:

cache:
  lock_dir: '/tmp/'


Cheers,

Anne

2016-07-26 22:45 GMT+02:00 Pestereva, Anna <apestereva at aerialservicesinc.com
>:

> Attila,
>
> thank you for the suggestion! I can't see anything abnormal in our servers
> utilization metrics though.. Also the errors don't seem to depend on a
> single data source or even single kind of source or cache config, which
> makes it quite confusing..
> Will see if updating Mapproxy version will have a positive effect.
>
> Anna
>
> On Tue, Jul 26, 2016 at 5:38 AM, BERÉNYI Attila <aberenyi at gislab.hu>
> wrote:
>
>> Hi there,
>>
>> We've been fighting the same error for the last couple of days, and it
>> turned out that the root cause is a data error (actually a character
>> encoding issue in the labels) - basically this means that the lock issue in
>> its own is not really helpful.
>>
>> You've mentioned that the data is coming from an NFS share - maybe worth
>> checking the I/O rates?
>>
>> Cheers,
>> Attila
>>
>> Pestereva, Anna <apestereva at aerialservicesinc.com> ezt írta (időpont:
>> 2016. júl. 26., K, 0:45):
>>
>>> Well, so far the most sure fix has been to explicitly configure caches
>>> with *disable_storage: true*. Although it is a relief to not see errors
>>> without changing functionally for most layers (since cache is not stored
>>> anyway for mixed format sources) - the original question remains open, why
>>> would those errors appear in the first place? We'd prefer to store tiles
>>> for caches/sources that support it.
>>>
>>> Also, would it be correct to say that it is the best practice to
>>> explicitly disable storage for caches that don't save tiles anyway?
>>>
>>> On Fri, Jul 22, 2016 at 5:25 PM, Pestereva, Anna <
>>> apestereva at aerialservicesinc.com> wrote:
>>>
>>>> A little more information if it can help anyone notice the
>>>> reason/solution:
>>>>
>>>> - errors occur with caches based not on just mixed sources, but also
>>>> with caches based on single wms source, where cache tiles are being
>>>> physically saved to disk.
>>>> - errors occur only with the most frequently used caches
>>>> - configuring and using a new cache with all the same settings, but a
>>>> new name, helps temporarily. For some time any errors stop, but after the
>>>> popular layer is used a bit, errors start appearing again although at a
>>>> slower rate than before.
>>>>
>>>> Will be glad to hear any thoughts!
>>>> Thanks!
>>>>
>>>> --
>>>> *Anna Pestereva, GISP | Application Developer & Cartographer*
>>>> *Aerial Services, Inc. (ASI) *
>>>> <http://aerialservicesinc.com/photoblogmetry/>
>>>>
>>>
>>>
>>>
>>> --
>>> *Anna Pestereva, GISP | Application Developer & Cartographer*
>>> *Aerial Services, Inc. (ASI) *
>>> _______________________________________________
>>> MapProxy mailing list
>>> MapProxy at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapproxy
>>
>> --
>> BERÉNYI Attila, PhD
>> ügyvezető
>>
>> GISLab Consulting Kft.
>> H-1031 Budapest, Kadosa utca 59.
>>
>> M: +36 20 457 1800
>> W: http://gislab.hu
>>
>
>
>
> --
> *Anna Pestereva, GISP | Application Developer & Cartographer*
> *Aerial Services, Inc. (ASI) *
> <http://aerialservicesinc.com/photoblogmetry/>
>
> _______________________________________________
> MapProxy mailing list
> MapProxy at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapproxy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapproxy/attachments/20160727/13731eca/attachment.html>