Open YoelRidgway opened 3 months ago
I'm having the same problem.
Does it work either of you with previous versions? what is the last version that worked for you?
I am actually running: Tileserver-gl v4.4.10, and get this error.
I am new to the project I'm working on so can't comment on the last version that worked.
For me, it mostly doesn't work. However, every once in a while I'll try again and it works (where I didn't change anything). It is sort of hit and miss when it works.
It happens when I run: docker-compose up When it works, I get: tileservergl | Starting tileserver-gl v4.4.10 tileservergl | Using specified config file from config.json tileservergl | Starting server tileservergl | Listening at http://[::]:8080/ tileservergl | Style "dark_offline" changed, updating... tileservergl | Style "dark_online" changed, updating... tileservergl | Style "dark_terrain_offline" changed, updating... tileservergl | Style "dark_terrain_online" changed, updating... tileservergl | Style "legacy" changed, updating... tileservergl | Startup complete tileservergl | GET /health 200 2 - 2.156 ms
When it doesn't work, I get: tileservergl | Starting tileserver-gl v4.4.10 tileservergl | Using specified config file from config.json tileservergl | Starting server tileservergl | Listening at http://[::]:8080/ tileservergl | Style "dark_offline" changed, updating... tileservergl | Style "dark_online" changed, updating... tileservergl | Style "dark_terrain_offline" changed, updating... tileservergl | Style "dark_terrain_online" changed, updating... tileservergl | terminate called after throwing an instance of 'std::runtime_error' tileservergl | what(): Failed to open X display. tileservergl exited with code 0
The docker image uses xvfb to provide X display. So the only thing i could think of is your cpu doesn't meet the requirements for it to emulate open-gl. What cpu and os are you running on?
I ran into something like this running directly on windows 2022 when i ran on a vitual server, since it didn't support opengl. There I had to force it to use mesa3d, which is am emulated open-gl similar to xvfb
the crash is likely happening when you visit the index page, where it needs to render thumbnails, or loading a rendered tiles. since this is when maplibre-native needs X display to render.
We have found that when using xvfb in maplibre-native ci workflows, it does fail with that error sometimes. it seemed to be a known xvfb issue
Yeah it sounds like a resource issue. however, I have lots of resources. Here is my system summary:
Also, my docker-compose.yml file has a lot of resources assigned: mem_limit: 24G cpus: '8.0' deploy: resources: limits: cpus: '8.0' memory: 24G reservations: cpus: '8.0' memory: 24G
Are you able to test swapping these two packages around and see if it makes a difference https://github.com/maptiler/tileserver-gl/blob/master/src/serve_rendered.js#L5-L11
Edit: I guess this is a slightly different error, so probably not it.
We have found that when using xvfb in maplibre-native ci workflows, it does fail with that error sometimes. it seemed to be a known xvfb issue
I found that as long as there is a style.json file in the folder, starting the Docker container will result in this error. However, this issue almost never occurs on Windows.
We have found that when using xvfb in maplibre-native ci workflows, it does fail with that error sometimes. it seemed to be a known xvfb issue
I found that as long as there is a style.json file in the folder, starting the Docker container will result in this error. However, this issue almost never occurs on Windows.
Specifically, this error does not appear locally. However, when previewing the raster, an error occurs: [error: failed to parse json: the document is empty. at offset 0] /GET xxxxx/xx512/0/0/0.png 500.
Hello there. I'm using
tileserver-gl v4.11.1
and I'm getting the classic:Normally this happens when the x display server is not running, however I'm running with docker... Are there any suggestions on how I can investigate this issue? I'm not sure where to start. This issue happened a few times on my local machine, but restarting would do the trick, but now it is hosted on a remote server and it is happening every time.