Error: ENOENT with default docker instructions, after rendering two tiles

[matkoniecz]

full log at https://gist.github.com/matkoniecz/0a2338b406be2e7ae6b1e13035c05a91

kosmtik_1  | [httpserver] /openstreetmap-carto/tile/4/7/7.png?t=1503340688420 200
kosmtik_1  | [httpserver] /openstreetmap-carto/poll/ 200
kosmtik_1  | [httpserver] /openstreetmap-carto/tile/4/7/8.png?t=1503340688420 200
kosmtik_1  | [Core] Loading project from project.mml
kosmtik_1  | [Core] Creating metatiles cache dir tmp/openstreetmap-carto/meta
kosmtik_1  | [Core] Deleting previous metatiles tmp/openstreetmap-carto/meta
kosmtik_1  | /usr/lib/node_modules/kosmtik/src/back/Project.js:130
kosmtik_1  |             if (err) throw err;
kosmtik_1  |                      ^
kosmtik_1  | 
kosmtik_1  | Error: ENOENT: no such file or directory, unlink 'tmp/openstreetmap-carto/meta/4.4.4.lock'
kosmtik_1  |     at Error (native)
openstreetmapcarto_kosmtik_1 exited with code 1

uname -a
Linux grisznak 4.10.0-32-generic #36~16.04.1-Ubuntu SMP Wed Aug 9 09:19:02 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

docker-compose --version
docker-compose version 1.8.0, build unknown

[kocio-pl]

Maybe this - and maybe also #2755 - is some old Kosmtik error, because I don't see anything like this with current git version. Unfortunately there was no Kosmtik release from February.

@nebulon42 What do you think about tagging 0.0.16 and publishing it on npm repo?

[nebulon42]

What do you think about tagging 0.0.16 and publishing it on npm repo?

I thinking of this for some time now and it would not hurt. Will do next week if I don't forget. As an memory aide I would ask you to create a ticket on the kosmtik repo.

[nebulon42]

2755 is unrelated to Kosmtik.

[kocio-pl]

With Kosmtik 0.0.16 released we can revisit this issue. BTW: currently we offer no information how to update docker images/containers.

[nebulon42]

True. You have to rebuild the images. You can do that directly by calling docker build -f Dockerfile . or you can also remove the corresponding images. You can list images by issuing docker images and when you have their hash you can run docker rmi hash. You might be told that the image is used by a stopped container in which case you first have to run docker rm container-hash before you can remove the image.

When you removed the images they will get (re-)built when you run docker compose the next time.

[kocio-pl]

I was not able to recreate this problem with new containers (and I also don't remember it with the old ones). The only idea I have is that maybe this:

kosmtik_1 | [Core] File DOCKER.md changed on disk

meant changing git branch and removing tmp directory? But I made a checkout and it didn't touch files in tmp - and it shouldn't, because it is in .gitignore, but maybe it wasn't then?

[matkoniecz]

Fortunately I am unable to replicate this problem.