|
tile.openstreetmap.org debug Server Stats Cache Server: sarkany.openstreetmap.org Render Server: rhaegal.openstreetmap.org Load Average: 14.94 File Status simplified-land-polygons-complete-3857.zip last modified: Wed Nov 11 08:03:27 2020 simplified-water-polygons-split-3857.zip last modified: Wed Nov 11 08:03:46 2020 ne_110m_admin_0_boundary_lines_land.zip last modified: Sun Jul 22 18:07:58 2018 land-polygons-split-3857.zip last modified: Wed Nov 11 08:04:25 2020 water-polygons-split-3857.zip last modified: Wed Nov 11 08:05:31 2020 antarctica-icesheet-polygons-3857.zip last modified: Wed Nov 11 08:06:13 2020 antarctica-icesheet-outlines-3857.zip last modified: Wed Nov 11 08:06:19 2020 Browser Request Headers CONTEXT_DOCUMENT_ROOT: /srv/tile.openstreetmap.org/cgi-bin/ CONTEXT_PREFIX: /cgi-bin/ DOCUMENT_ROOT: /srv/tile.openstreetmap.org/html GATEWAY_INTERFACE: CGI/1.1 HTTPS: on HTTP_CACHE_CONTROL: max-age=1209600 HTTP_CONNECTION: keep-alive HTTP_HOST: tile.openstreetmap.org HTTP_SURROGATE_CAPABILITY: sarkany.openstreetmap.org="Surrogate/1.0 ESI/1.0" HTTP_USER_AGENT: NONE HTTP_VIA: 1.1 sarkany.openstreetmap.org (squid/4.11) HTTP_X_FORWARDED_FOR: 213.160.XXX.XXX, 127.0.0.1 LC_CTYPE: C.UTF-8 PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin QUERY_STRING: REMOTE_ADDR: 37.17.173.8 REMOTE_PORT: 22236 REQUEST_METHOD: GET REQUEST_SCHEME: https REQUEST_URI: /cgi-bin/debug SCRIPT_FILENAME: /srv/tile.openstreetmap.org/cgi-bin/debug SCRIPT_NAME: /cgi-bin/debug SCRIPT_URI: https://tile.openstreetmap.org/cgi-bin/debug SCRIPT_URL: /cgi-bin/debug SERVER_ADDR: 10.5.0.77 SERVER_ADMIN: webmaster@openstreetmap.org SERVER_NAME: tile.openstreetmap.org SERVER_PORT: 443 SERVER_PROTOCOL: HTTP/1.1 SERVER_SIGNATURE: Apache/2.4.41 (Ubuntu) Server at tile.openstreetmap.org Port 443 SERVER_SOFTWARE: Apache/2.4.41 (Ubuntu) Confirmed that the tile is broken on sarkany. I tried to initiate a re-rendering/re-caching but as of now I'm unsure if the /dirty method still works (maybe someone else or SomeoneElse could confirm?). It does look as only this tile is affected, other tiles surrounding this one are not. Maybe related to an outage of the sarkany cache for about ~ 1 hour today at midnight?
(18 Nov '20, 14:04)
Spiekerooger
Can you open https://www.openstreetmap.org/#map=12/49.1131/18.9420 and do a hard refresh? It should initiate a reload of the tile into the cache.
(18 Nov '20, 14:48)
Spiekerooger
Ok I did, but I see no changes.
(18 Nov '20, 18:55)
marianskrisa
|
|
This is the tile, what is broken? 2
That tile form sarkany won't display in (at least) firefox. FF says the png contains errors. So I can confirm what marianskrisa says and I've tried a hard refresh from www.openstreetmap.org, it won't help - as nginx/squid thinks there is a fine file. It does smell as if the png has some extra or mising bytes in there.
(19 Nov '20, 14:20)
Spiekerooger
2
(for Andy Mackey's benefit) The actual location that tiles are loaded from depends where you are in the world. The person who asked this question is trying to load this tile from an address that translates to http://37.17.173.8/12/2263/1404.png - that gives an error. A next-door tile https://37.17.173.8/12/2263/1405.png works OK. The thing that determines what tile server you get is your DNS, so in the UK I currently get 185.73.44.167, also known as london-02.tile.openstreetmap.org, when I try to load anything from b.tile.openstreetmap.org. Separately to the PNG error with this tile trying to load, https://37.17.173.8/12/2263/1405.png will of course get a browser certificate warning, because the certificate on the web server is valid for "b.tile.openstreetmap.org" (among others) but not for the raw address 37.17.173.8.
(19 Nov '20, 14:52)
SomeoneElse ♦
To test this further you can manipulate your local hosts file in setting 37.17.173.8 as the A record for tile.openstreetmap.org. If you then open https://www.openstreetmap.org/#map=12/49.1131/18.9420 in FF you'll see the problem as shown by marianskrisa below. And even a hard refresh won't work. I know that one tile is not the world out of those billions of tiles in 55+ tile caches but it would be really nice to find a solution to solve this by other means than asking the SysOWG. Sth. magic without having to ssh into sarkany ;)
(19 Nov '20, 15:49)
Spiekerooger
(20 Nov '20, 06:28)
marianskrisa
|
Looks fine here but as it is cache-dependent, can you post the output of https://tile.openstreetmap.org/cgi-bin/debug ?
For completeness https://37.17.173.8/12/2263/1404.png loads in Chrome (including incognito) for me as well and also FWIW Internet Explorer (!). It doesn't mean there isn't a problem with that tile though.