<div dir="auto">Jon, <div dir="auto">This issue is probably related to <a href="https://github.com/OSGeo/gdal/issues/1244">https://github.com/OSGeo/gdal/issues/1244</a> and was fixed in 2.4.4</div><div dir="auto"><br></div><div dir="auto">--</div><div dir="auto">Thomas</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 24 févr. 2020 à 05:46, Jon Seymour <<a href="mailto:jon@upowr.com.au">jon@upowr.com.au</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">G'day,<div><br></div><div>I am trying to get to the bottom of some errors I have been experiencing with gdal 2.4.2 + Python 3 running in a long-running debian container on AWS ECS. The files I am trying to load are VRT (actually named .tif) that reference actual .tif files hosted in the same S3 bucket.<br><br>Most of the time the access works, the symptom is that if the container has been running for a long time, then the gdal.Open() returns null and logs an ERROR 4 to the stderr. For example:<br><br>ERROR<span style="color:rgb(45,45,45);font-family:"Lucida Console",Monaco,monospace;font-size:12px;white-space:pre-wrap"> </span>4<span style="color:rgb(45,45,45);font-family:"Lucida Console",Monaco,monospace;font-size:12px;white-space:pre-wrap">: `/vsis3/acme-foo-bar/baz/quux.tif' not recognized as a supported file format
</span><br>If the container is restarted, then the access works as expected. Indeed, if I call gdal.VsiCurlClearCache(), then the access works as expected, so the issue is not the AWS credentials. Indeed, verbose vsicurl logging indicates that there are no 4xx or 5xx errors on any request (almost all the requests return.a 206 Partial Response response code).<br><br>I was initially using gdal 2.4.0 with IAM role-based credentials and discovered this issue (<a href="https://github.com/OSGeo/gdal/issues/1593" target="_blank" rel="noreferrer">https://github.com/OSGeo/gdal/issues/1593</a>) that looked very similar to the issue I was having. <br><br></div><div>However, I have since upgraded the library to gdal-2.4.2 and an issue with identical symptoms persists - occasionally. I have even stopped using IAM role based credentials and switched to using explicitly managed AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables but the issue persists - occasionally. By occasionally, I mean that I can't reproduce the problem at will even with files for which it happens initially. The fact that I do not see any 4xx or 5xx errors indicates to me that this is not a AWS credentials issue.<br><br>I have enabled vsicurl verbose logging and have observed that I get a 206 response of the correct length (1985, in my case), indicating that the request to AWS S3 has not actually failed and probably has returned the expected response.<br><br>It does seem suspicious to me that a call to gdal.VsiCurlClearCache() appears to resolve the issue immediately, but it isn't clear why that works or what the root cause of the underlying issue is.<br><br>Any suggestions about how I could debug this would be gratefully accepted.</div><div><br></div><div>jon.<br><br><br><br><br><br><br></div></div>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank" rel="noreferrer">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a></blockquote></div>